[Bug]: Issues with Korean Input in the Terminal

[E1jeong]

Operating system

Windows

Orca version

1.4.148

Details

As shown in the image, an issue occurred while typing in Korean.
The Enter key didn’t work, and the left and right arrow keys on the keyboard also behaved strangely.

In addition to this, there were instances where characters disappeared while typing in Hangul. Also, when the cursor is positioned on a Hangul character and I press Shift+Enter, a line break occurs along with that character.

[AmethystLiang]

looking into it!

[asiaenv8053]

Another Windows data point, plus a mechanism hypothesis that might help narrow this down.

Environment

• Windows 11 (build 26200), Orca 1.4.158
• Korean 2-set IME (Windows built-in)
• Integrated terminal pane, with an agent TUI running in it

Symptom A — an in-composition chunk is reverted wholesale

Not a single dropped syllable: the whole run of text I just typed disappears. Typing 한국, for example — if the terminal repaints before the syllable is committed, what was on screen as 한국 vanishes entirely rather than losing one character.

Hypothesis: it looks like Orca periodically polls / captures terminal state and re-renders from that snapshot. The snapshot comes from the PTY side, which has no knowledge of the IME preedit buffer — uncommitted Hangul only exists in the IME and the renderer, never in the PTY. So when a poll lands mid-composition, the repaint overwrites the visible preedit with the last committed PTY state and the in-progress chunk is gone. That would explain:

• it is timing dependent (it happens when a poll boundary lands mid-composition) rather than keystroke dependent;
• a whole chunk disappears rather than one character;
• Latin input is unaffected, since it commits per keystroke and never has a preedit living outside the PTY state.

If that is the shape of it, the fix would be to suppress or defer the periodic redraw while a composition is active (compositionstart → compositionend), or to reapply the preedit on top of the refreshed buffer.

I have not verified this against the source — it is inferred from the timing-dependent, chunk-sized nature of the loss, so treat it as a starting point rather than a diagnosis.

Symptom B — input latency

Separate from the revert: Hangul typing in the terminal feels noticeably laggy compared to Latin, with a small but consistent delay between keystroke and glyph. It is not tied to the disappearing bug — it happens on every session. Improving this would be very welcome.

Possibly related, in case they share a root cause: #9738 (macOS, chat input, single-character drops), #9862 (Linux/IBus, duplicated or dropped), #10842. This differs from #10343 and #8038, which are about Enter / Shift+Enter at commit time rather than a composition being wiped by a repaint.

Happy to capture logs or test a build if that would help.

[pobbye-star]

Another Windows data point on 1.4.163 — and one symptom I don't see described above yet: the cursor fails to advance after each composed syllable.

Environment

• Windows 11 Pro build 26200, Orca 1.4.163 (winget), Windows built-in Korean 2-set IME
• Reproduces in all 5 CLI agent tabs we run (Claude Code, Codex, OpenCode, Antigravity, Grok) — so it is the integrated terminal layer, not any specific agent TUI. ASCII typing is unaffected.

Symptom — cursor advances one syllable late

While typing Hangul continuously, after a syllable commits the cursor stays on the same cell; it only moves one cell forward when the next syllable's first jamo is typed. The user describes it as: "한 글자 치고 나면 한 칸씩 나가지지 않고 제자리에 있다가 두 번째 글자에서 또 한 칸 넘어간다."

Symptom — stray line breaks mid-word (likely the same root as #11878)

Text submitted while the bug is active comes through with unintended newlines between syllables. Verbatim capture of one submitted answer:

한
글짜 치고 나면 한 
칸씩 나가지지 않고 제 자리에 
있다가 두
번째 
글짜에서 또 한칸 넘어간다.

Note the breaks after 「한」「두」 — consistent with the Shift-state / composition-commit confusion hypothesized in #11878 (e.g. 「글짜」 starts with a Shift-adjacent key sequence), though here breaks also appear around syllables with no double consonant.

The user reports this appeared recently after an update ("이상해졌다") — it was not happening before. Happy to provide keystroke-level repro or logs if that helps.

[pobbye-star]

Follow-up — regression window narrowed: on this machine the symptoms (cursor advancing one syllable late + stray mid-word line breaks, all agent tabs) started immediately after the auto-update to v1.4.163, applied today 07:35 KST (release published 2026-07-31 22:44 UTC). On v1.4.162 (used through yesterday) Korean typing was fine. So at least this cursor-lag variant looks like a 1.4.162 → 1.4.163 regression on Windows (build 26200, built-in Korean 2-set IME).

[pobbye-star]

Confirmation: rolling back to v1.4.162 (over-install of the release setup, pending updater cache cleared) fully restores normal Korean typing on the same machine — cursor advances per syllable and no stray line breaks. Regression is confirmed 1.4.162 → 1.4.163 (Windows 11 build 26200, built-in Korean 2-set IME, integrated terminal).

[pobbye-star]

[한국어 사용자 주의 / Advisory for Korean users]

v1.4.163은 한국어(한글) 입력에 치명적인 불편이 있습니다. 당분간 v1.4.162 사용을 권합니다.

Windows에서 v1.4.163으로 자동 업데이트된 직후, 통합 터미널의 모든 에이전트 탭(Claude Code·Codex·OpenCode 등 전부)에서 다음 증상이 시작됩니다:

• 한 글자를 조합해도 커서가 제자리에 머물다가 다음 글자를 칠 때에야 한 칸 전진
• 연속 타이핑 중 단어 중간에 의도하지 않은 줄바꿈이 끼어듦 (제출된 텍스트가 여러 줄로 쪼개짐)
• 위 스레드의 글자 사라짐·방향키 이상 증상도 동일 계열로 보임

당분간의 대응 (실측 검증됨):

1. v1.4.162 설치본을 받아 덮어 설치: https://github.com/stablyai/orca/releases/download/v1.4.162/orca-windows-setup.exe
2. %LOCALAPPDATA%\orca-updater\pending 폴더를 삭제 (1.4.163 재적용 방지)
3. 가능하면 자동 업데이트를 꺼 두고, 이 이슈에 수정이 공지된 뒤 업데이트 재개

v1.4.162로 되돌리면 한글 입력이 완전히 정상으로 돌아오는 것을 확인했습니다 (Windows 11 build 26200, 내장 두벌식 IME).

---

English TL;DR: v1.4.163 severely breaks Korean IME typing in the integrated terminal on Windows (cursor lags one syllable behind; stray line breaks split words). Verified workaround: roll back to v1.4.162, clear the pending updater cache, and hold updates until a fix lands. Korean users should stay on v1.4.162 for now.

[edd-one-out-sion]

Additional deterministic reproduction on Orca 1.4.163.

Environment

• Windows
• Orca 1.4.163
• Codex CLI 0.146.0
• Observed in the Orca Codex input. Korean typing in Notepad and Claude Code was normal on the same machine.

Minimal reproduction

Type the following 42-character string without intentionally inserting a newline:

가나다라마바사아자차카타파하가나다라마바사아자차카타파하가나다라마바사아자차카타파하

Expected

The same 42 characters, with no newline or spaces inserted.

Actual stored input

가나다라마바사아자차카타파하가나다라마바사아자차카타파하가나다
  라마바사아자차카타파하

Inspection of the persisted Codex history entry showed:

• 45 characters total
• exactly 1 unintended LF newline and 2 unintended spaces
• removing whitespace produces the exact original 42-character string, so no Hangul characters were lost

This looks like whitespace being inserted near the input wrapping boundary.

Disclosure: This report was written and posted by an AI assistant on behalf of the user, based on the user's reproduction and a locally verified input record.

[pobbye-star]

Critical remote-input variant: Shift modifier is lost through both AnyDesk and Chrome Remote Desktop

This is not limited to one agent CLI or one remote-control product.

Environment

• Host OS: Windows 11 Pro, build 26200
• Orca runtime observed during investigation: 1.4.169 (the 1.4.171 update had been announced, but the live runtime had not yet restarted into it)
• Remote-control clients: AnyDesk and Chrome Remote Desktop
• Keyboard/input: Korean keyboard/IME in Orca

Reproduction

1. Connect to the Windows host remotely with AnyDesk.
2. Focus an Orca terminal/input surface and use the Korean keyboard/IME.
3. Hold Shift to enter a shifted symbol or while composing Hangul.
4. Repeat the same test through Chrome Remote Desktop.

Actual

• Shift is effectively lost inside Orca in both remote-control paths.
• Shifted symbols, including ?, cannot be entered reliably.
• Hangul input also becomes erroneous while this is happening.
• The behavior is the same with AnyDesk and Chrome Remote Desktop, so this does not look like an AnyDesk-only key-map problem.

Expected

Orca must preserve modifier state from remote desktop input exactly as it does from a local keyboard. Shifted punctuation and Korean IME composition must remain usable.

Why this needs priority

This blocks normal Korean remote work in Orca: users cannot reliably write prompts, commands, paths, or punctuation, and cannot switch to another mainstream remote-control client as a workaround.

Please investigate the remote input / modifier-state transport path before terminal or IME composition handling. The cross-client reproduction is a strong indication that the loss occurs in Orca s handling of remotely delivered key events, rather than in one remote-control applications keyboard mapper.

I can retest after a fully restarted 1.4.171 runtime, but the current live runtime was still reporting 1.4.169 when this was observed.