claude-code - 💡(How to fix) Fix [BUG] IME pre-edit buffer cleared by UI redraws during candidate selection — McBopomofo / 小麥注音, macOS, iTerm2 [2 comments, 2 participants]

What's Wrong?

When typing Chinese via an IME in Claude Code, the pre-edit buffer is destroyed by UI redraws during the uncommitted composition phase — after phonetic input is complete but before the user has finalized which characters to commit.

Concrete example with McBopomofo (小麥注音): I type ㄔㄥˊ ㄕˋ. McBopomofo uses inline pre-edit rendering — it shows the top-guess characters directly in the composition area (e.g. "程式") without a floating candidate popup. From here I can cycle through alternative homophones (e.g. 城市, 成事) using the up/down arrow keys, or press Enter to commit the current choice. If the assistant emits any new token before I commit, the entire pre-edit is wiped — typed Zhuyin input and current candidate both gone.

This is different from #43381 (characters invisible during typing). In my case, characters DO render inline while typing — the bug is that composition state isn't preserved across redraws while I'm still selecting among homophones.

What Should Happen?

The IME pre-edit buffer should survive assistant-driven redraws. Composition should only end on explicit user action: compositionend (commit via Enter / Space / number selection) or cancel (Esc). This is how readline, vim, and every modern TUI behave.

Steps to Reproduce

1. macOS with McBopomofo (小麥注音, https://mcbopomofo.openvanilla.org/) as the active input source.
2. Launch claude in iTerm2.
3. Send a prompt that produces a long streaming response (e.g. write a 500-word essay).
4. While Claude is streaming, in McBopomofo type ㄔㄥˊㄕˋ — a homophone resolving to 程式 (program) / 城市 (city) / 成事 (succeed). Leave the pre-edit uncommitted (do not press Enter; cycle candidates via up/down arrow keys).
5. Observe: on the next assistant-driven redraw, the pre-edit is wiped. Input field is empty again.

Expected: Pre-edit survives redraws; I can pick 程式 vs 城市 on my own schedule. Actual: Composition state destroyed mid-selection; typed input lost.

Environment

• Claude Code: 2.1.107
• macOS: 15.7.4 (Sequoia, Apple Silicon)
• Terminal: iTerm2 3.6.9
• Shell: zsh
• IME: McBopomofo 小麥注音 (popular third-party Zhuyin IME in Taiwan)
• Likely also affects: macOS native 注音 / 拼音, and any CJK IME that uses a pre-edit composition buffer.

Impact / Use Case

The primary workflow this breaks: while Claude is streaming a response, I want to compose my next prompt so I'm ready to send the moment the assistant finishes — making use of the otherwise-idle waiting time. This is a natural productivity pattern in any chat UI.

For CJK IME users this is impossible. Every streamed token triggers a redraw that destroys my in-progress composition while I'm still cycling candidates. The only options are:

• (a) Sit idle while Claude works, then start typing from scratch after the stream ends — wasted time on every turn.
• (b) Compose in another app and paste — defeats the interactive CLI UX.

English users don't hit this because each keystroke commits immediately. CJK IME users pay this tax every single turn.

Additional Context

• Trigger is UI redraw, not keystroke handling. Typing keys alone works fine — it's assistant output that destroys the composition.
• macOS built-in Dictation has the same symptom on CJK layouts (dictation writes into the same pre-edit buffer, gets wiped by redraws).
• Only reliable workaround: compose Chinese in another app, then paste. Defeats interactive CLI UX.