Desktop app: message input box refills with previously sent message after every send

Also seeing this. Claude Code desktop app, Code tab, Windows 11. After sending a message with Enter, the just-sent text reappears in the input box a short while later, requiring a manual clear before typing the next message. Happens repeatedly across a session; noticed while using Japanese IME input.

Same bug on macOS, so it's not Windows-only. I think I've found the cause: it's caused by dictation.

Environment

• Claude desktop app 2.2553.1 (c38127), build dated Sept 18, 2026
• macOS 26.2, Apple M4 Mac
• Happens in both the Chat and Code tabs, on every message
• Input method: dictation within the app (using the microphone button below the text input box)

What happens

1. Start dictation and speak a message. The text appears live in the input box as expected.
2. Press Enter to send. The message sends and the box clears.
3. The dictation indicator stays on. Sending the message doesn't end the dictation session.
4. When dictation times out, macOS dictation (I suspect this is what is being used under the hood) delivers its final copy of the dictated text, and the app inserts it into the now-empty box.

So the text arrives twice: once live while dictating, and again when the session ends. That's why the old message "reappears" a little after sending, often while the reply is still streaming.

Workaround: turn dictation off (press the dictation shortcut again or click the mic indicator) before pressing Enter. Then nothing comes back.

Likely fix: end or cancel any active dictation session when a message is sent or the input is cleared, the way most native macOS text fields do.

The example text in #95517 ("Number one, no, I do not… The sound is a bit of a pop") also reads like dictated speech, so the Windows reports may have the same cause through Windows voice typing or another dictation tool.

Confirming on macOS, same build as @GeneralMelchett above: Claude desktop 2.2553.1, Code tab. Dictation is the trigger here too.

A variant that reproduces every time, with the mic left open across the send:

1. Turn the composer mic on and dictate.
2. Press Enter while the mic is still on. The message sends and the composer clears.
3. Turn the mic off.

Some or all of the already-sent dictation is then re-inserted into the composer.

Expected: sending resets the dictation buffer. Ideally the mic stays on with an empty buffer, so continuous dictation works — speak, Enter, keep speaking — without leftover text prepending to the next message.

I filed #95564 for this before finding this issue; it looks like the same root cause and is currently labelled platform:windows only, so it may be worth merging into this one. Likely also related to #93778, where the dictation session keeps its own copy of the text and writes it back over the composer.