macOS IME preedit text leaks into input as a ghost attachment chip

Summary

When using a Chinese IME (both Apple Pinyin and Sogou Pinyin reproduce) in Chinese mode, typing Latin letters and pressing Enter correctly commits the English text — but the IME composition's candidate character is wrongly absorbed by the TUI as a ghost mention/attachment chip that sticks around in the input area.

Environment

• Claude Code: 2.1.143
• macOS: 26.5 (25F71), Apple Silicon
• IMEs reproduced: 苹果拼音 (Apple Pinyin), 搜狗输入法 (Sogou Pinyin)

Repro

1. Switch IME to Chinese mode (Apple Pinyin or Sogou — both reproduce, ruling out IME-specific behavior).
2. In the Claude Code input area, type dai then press Enter.
3. dai correctly appears as English text on the input line.
4. But: a chip with the Chinese candidate character (e.g. 代) plus an × close button appears attached to the input, as if it were a file mention or attachment.

A user-supplied screenshot shows the chip rendered below the input line, styled the same as a mention/attachment pill.

Expected

Either the IME composition is fully consumed and discarded when the user commits the Latin text, or the candidate is shown only as inline IME preedit while composing and never persists after commit. The TUI should not turn the leftover preedit string into an attachment chip.

Actual

The candidate character persists as a chip until manually dismissed via ×. It appears to be treated as if it were a mention/attachment token.

Notes

• codex CLI in the same terminal / IME state does not exhibit this — it correctly consumes the IME composition and only the committed English text ends up in its input. So the issue is specific to Claude Code's TUI input handling of macOS IME marked text (NSTextInputClient preedit), not a terminal or IME bug.
• Workaround: switch IME to ABC / English before typing, so no IME composition takes place.

Suggested area

Likely in the TUI input layer's handling of IME composition / marked text — possibly mistaking trailing preedit bytes for a mention trigger.