Repository navigation
[Bug]: iPhone voice input sends the raw transcript and drops manual edits made before send #15129
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- Open a thread in the iPhone app.
- Tap the mic in the composer and dictate a message.
- When the transcript appears in the composer, correct it by hand (fix misrecognised words, retype parts).
- Press send.
Expected behavior
The message sent is the text currently in the composer, including the manual edits.
Actual behavior
The original, unedited transcript is sent. The manual edits are discarded when send is pressed.
For example, the user dictated something like "Firstmate is running in another session". It was transcribed as "First mate is running inane", corrected by hand, and the uncorrected "First mate is running inane" was still what reached the thread. This happened on several consecutive messages in the same thread.
Impact
High for voice users. Correcting a transcript is the normal way to fix recognition errors, and it silently does nothing. Wrong text is sent to the agent, and the user only notices afterwards, when the agent acts on it.
Version or commit
iPhone app, as installed on 2026-10-03. Exact build unknown.
Environment
iPhone app (iOS), connected to a T3 Code server on Linux running Claude Code sessions.
Logs or stack traces
None collected.
Workaround
Retype the message instead of editing the dictated text, or clear the composer and type it from scratch.
Activity
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the clear report, @Baqiwaqi! This is a bug in iPhone voice input. When a dictation is confirmed, the transcript is written into the composer draft once, and Send queues whatever is still in that draft. The text on screen can show your later correction while the draft still holds the original transcript, so the thread receives the unedited wording, as in your "First mate is running inane" example.
Why it happens
There's no separate transcript kept for sending.
VoiceInputController.commitDraft(packages/client-runtime/src/voice-input/controller.ts) inserts the transcript into the draft. The editor stays read-only until transcription finishes, and the transcript is then applied to the controlled iOS text view (T3ComposerEditorView.swift).Edits you make after that happen in the iOS text view, but Send never reads the text view. It reads the draft snapshot (
getComposerDraftSnapshot().textinapps/mobile/src/state/use-thread-composer-state.ts), which can still hold the original transcript.The same composer path is used for threads, new tasks, and scheduled-task prompts on iPhone, so all three can drop these edits. Android has no on-device transcriber, and the server isn't involved.
Related, not duplicates
No open or merged PR fixes this yet. The fix needs Send to queue the text that's actually in the editor when you press it, including corrections made after the transcript appears. A maintainer will decide on the fix direction.
Until then, your workaround is the reliable one: retype the message, or clear the composer and type it fresh, rather than editing the dictated text.
juliusmarminge commentedon Nov 12, 2026
This is the same problem as #17422, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.