[BUG] iOS app (Code tab): the first character typed after focusing the input field is force-committed, breaking Japanese IME composition

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In the Claude iOS app's Code tab (Remote Control session), the first character typed
after tapping into the message input field is immediately force-committed by the app.
iOS's marked text (composition) state is cleared, so that character cannot be converted
(変換) and a dakuten/handakuten cannot be applied to it.
Every character after the first composes normally.
The clearest proof is the keyboard layout itself. On the iOS 12-key kana keyboard, the
keys change depending on whether a composition is active:
| Key position | While composing | When nothing is composing |
| --- | --- | --- |
| right column | 次候補 / 確定 | 空白 / ⏎ |
| bottom-left | 小゛゜ (dakuten) | ^_^ (kaomoji) |
In the attached video, the instant the first character appears in the field the keyboard
is already showing 空白 / ⏎ / ^_^ — i.e. iOS itself considers the character committed.
The candidate bar has also switched from conversion candidates to predictive ones.
Because the keyboard is in the non-composing layout, the bottom-left key the user reaches
for to add a dakuten is no longer 小゛゜ but ^_^, so tapping it inserts a kaomoji.
Typing どうなってますか？ therefore produced: と^_^うなってますか?
Control case (same video, ~10 s later): the user deleted everything with backspace down to
an empty field WITHOUT tapping the field again, and retyped. This time the first character
stayed underlined, the keyboard stayed in the 次候補 / 確定 / 小゛゜ layout, the dakuten
applied correctly, and どうなってますか？ was typed with no problem.
That rules out "the field is empty" and "the send button flips from disabled to enabled"
as the trigger — both were equally true in the working case. The difference is the focus
event.
Suspected cause: something assigns to the text view's text (or the React Native
TextInput value prop) shortly after the field gains focus — a draft restore, or a state
sync on focus. Assigning text while markedTextRange is non-nil discards iOS's
in-progress composition.
Suggested fix: do not re-assign text / re-mount the input while
textView.markedTextRange != nil.
Impact: every Japanese message needs a throwaway first character or a delete-and-retype.
This most likely affects every IME-based language (Chinese, Korean, Vietnamese) for the
same reason, though only Japanese was tested here.

What Should Happen?

The first character should stay as uncommitted marked text (underlined), exactly as it
does in every other iOS app and as it does for the second and later characters in this
same field.
Concretely: typing と should leave it underlined so that the dakuten key turns it into ど,
and so that kanji conversion candidates apply to it.

Error Messages/Logs

Steps to Reproduce

1. Open a Code session in the Claude iOS app (Remote Control against a Mac host).
2. Switch the iOS keyboard to Japanese (12-key kana / flick), default settings.
3. Tap the message input field (placeholder "フィードバックを追加…") while it is empty.
4. Type one character, e.g. と.
5. Try to turn it into ど by tapping the dakuten key at the bottom-left of the keyboard.

Observed: と is already committed (no underline). The bottom-left key is ^_^, not 小゛゜,
so a kaomoji is inserted instead of a dakuten.

Control (works correctly): from that state, hold backspace until the field is empty, and
retype WITHOUT tapping the field again. Now the first character composes normally.

Reproduces every time.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

https://github.com/user-attachments/assets/628ad2c5-1db1-4b98-9f1e-ae601406815c

Attached video (15 s) shows both the failing case and the working control case back to
back. Only the input field and the keyboard are in frame.

Client: Claude iOS app, Code tab (Remote Control session).
Host: macOS, Claude Code 2.1.220.
Keyboard: iOS Japanese 12-key kana (flick), default settings.