[BUG] Desktop app: dictation mic is removed from the composer when an attachment is present
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 desktop app, the dictation microphone control disappears from the message composer as soon as a file is attached. With an attachment in the composer there is no way to dictate the message that goes with it — the control is not rendered at all. Attaching a file and then speaking the prompt used to work.
The desktop app also has no keyboard shortcut for dictation (#59400, closed as duplicate; #48305 for macOS), so hiding the button removes the only entry point. There is no fallback — the only workaround is to dictate first and attach second, which forces an arbitrary ordering on composing a message.
Dictation is an accessibility and input-preference feature. People who speak rather than type do not stop needing it when a file is involved, and the message accompanying an attachment is usually the longer one, since it has to explain what the file is and what to do with it. Conditionally rendering the mic on composer state makes the input method vanish at exactly the wrong moment.
What Should Happen?
The dictation microphone control should remain available whenever the composer is, regardless of whether an attachment is present. Attachments and dictation are orthogonal.
If the motivation is layout pressure from the attachment chip, the fix is to make room rather than drop the control:
- Keep the mic rendered and let attachment chips wrap onto their own row.
- If horizontal space is genuinely tight, collapse a lower-priority control, or move the mic into an overflow menu — visible, not absent.
- At minimum, ship a keyboard shortcut for dictation, so there is a route that does not depend on a button being on screen.
Error Messages/Logs
Steps to Reproduce
- Open the Claude desktop app on Windows 11 and start a new chat.
- Note the dictation microphone control in the message composer.
- Attach a file to the composer (paperclip button, drag-and-drop, or paste).
- Look at the composer controls again — the microphone is gone.
- With the attachment in place, there is no way to dictate the accompanying message.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown — an earlier desktop build; attaching and then dictating worked previously
Claude Code Version
Claude desktop app 1.37937.3 (Electron 42.10.0, Node 24.18.1) — desktop app, not the CLI
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
- This is about the Claude desktop app composer, not the Claude Code CLI, so the Platform and Terminal/Shell fields are not really applicable — they are set to the closest available option.
- Current workarounds: dictate the message first and attach the file afterward (existing composer text is preserved), or use Windows voice typing (Win+H), which works in the composer regardless of attachment state. Both are workarounds for a control that should not have been removed in the first place.
- Happy to supply screenshots of the composer before and after attaching if that helps triage.
5 Comments
Same defect, different trigger: the mic is also removed when the composer merely contains text, with no attachment involved.
Environment: Claude desktop app (Chat and Cowork) on Windows 11, and claude.ai in a browser. Empty composer shows the mic. Type or dictate a single character and the mic is replaced by the send arrow. No keyboard shortcut, no menu entry, no overflow item, so the only route back to dictation is to clear the box and lose what is already written.
That makes these one bug rather than two: the mic is conditionally rendered on composer emptiness, and an attachment and a character of text are just two ways of making the composer non-empty.
The text trigger is the more common one, and I would argue the more damaging, because it removes incremental dictation entirely: dictate a sentence, read it back, fix a word, dictate the next one. Under this behaviour a spoken message has to be produced in one uninterrupted take or not at all, and typing two words first locks the message into typing for the rest of its life.
On the layout-pressure hypothesis in the original report, the evidence is against it. The screenshot at the end of this comment is a maximised window on a desktop monitor with text in the composer. The button row holds a single "+" on the left and the send arrow on the right; the entire middle of the row is empty. Nothing is competing for that space.
More telling: the swap is not responding to available width at all. If it were a space calculation it would keep both controls at this width and collapse only on narrow viewports. It does not. That is the signature of one composer component behaving identically on every surface: a mobile idiom, where mic-swaps-to-send is genuinely justified by thumb-width constraints, applied uniformly to desktop and web where it simply deletes a control.
Anthropic's own CLI documentation describes the workflow this blocks as intended behaviour:
https://code.claude.com/docs/en/voice-dictation
The CLI's one restriction on a non-empty input exists for a concrete reason: its push-to-talk key is Space, which would otherwise type a space. The GUI has no equivalent constraint, because the mic is a button.
One classification note, since this issue has already been auto-labelled "invalid". This is not a transcription failure like #59849 or #71764, where the recogniser captures audio and produces no text. Nothing fails at runtime here. The control is simply not rendered. It is a UI regression in the composer, and it belongs with whoever owns that component rather than with the speech pipeline.
Minimum fix: keep the mic rendered alongside send whenever the composer is non-empty, at least above a mobile breakpoint, and insert the transcript at the cursor. Failing that, ship a dictation shortcut that works regardless of composer state (#48305).
<img width="1640" height="420" alt="Image" src="https://github.com/user-attachments/assets/381e743a-5cad-4d9b-809f-f19930baa668" />
Same on macOS, and the trigger is broader than attachments. The mic control is removed whenever the composer is non-empty, including plain typed text with no file attached. Mic and send appear to share a single control slot, so any content in the box claims that slot for send and there is no remaining way to start dictation.
Environment: MacBook Air (Apple Silicon), Cowork mode, macOS Dictation enabled.
Two additional observations:
Expected: the microphone control stays available regardless of composer contents, with new speech appended at the cursor rather than replacing existing content. Send appearing when the box becomes non-empty should not remove the only way to start dictation.
This is a dated regression, not a missing feature. Dictating into a composer that already held text worked on the morning of 2026-08-26 and was broken by 2026-08-27.
Confirming this is still present on a newer build: Claude desktop app 1.40609.0 (Electron 42.10.0, Node 24.18.1), Windows, in both Chat and Cowork.
Agreeing with the comments above that the attachment case and the typed-text case are one bug. From the user side it reads as one-and-done: use the mic once, accept the transcription with the checkmark, and the control is gone. Post an image and it's gone. Either way the only way to get it back is to clear the box, which means throwing away whatever is already in there.
The part that makes this more than a missing button is that it removes the ability to speak, stop, gather your thoughts, and keep speaking. That is how people actually talk. A dictation feature that only accepts one uninterrupted take is not really a dictation feature, and for anyone who speaks rather than types it is the difference between the app being usable and not.
Also worth flagging that the "invalid" label here came from the auto-labeler, not from a human triage pass. This is a real regression in the desktop composer.
Fifth confirmation. MacBook Pro, Chat mode, latest desktop build, full uninstall/reinstall didn't change it. Same account on the iPhone app still shows mic and voice-mode wave side by side and works the old way, so this is desktop-specific. My workflow is dictate, stop to look at a chart, screenshot it, keep dictating, add another screenshot, send once. That is now impossible. Agree with the above that the pause/resume loss is the real damage — a dictation feature that only takes one uninterrupted take isn't dictation.
Same on claude.ai web in Chrome, and I can confirm your read that it's not really about attachments: the mic disappears whenever the composer has any content, text included (that variant is #90117). It renders only in the fully empty state. Worth noting for the layout question: the current iOS app shows the mic and Send side by side with content present, screenshot in my consolidated report at #90618 so space isn't the constraint. Your dictate-first-attach-second workaround is the same one I landed on.
<img width="1594" height="316" alt="Image" src="https://github.com/user-attachments/assets/da1095f6-caf4-4641-85dd-aa6bee6eb824" />
<img width="1290" height="1763" alt="Image" src="https://github.com/user-attachments/assets/d550d6a6-90a3-468e-84c0-d1a0695711cb" />