[BUG] Desktop app: dictation mic is removed from the composer when an attachment is present

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:

The transcript is inserted at your cursor position and the cursor stays at the end of the inserted text, so you can mix typing and dictation in any order.

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:

1. Dictation into an empty composer works. The macOS menu bar mic indicator lights, text transcribes correctly into the box. Once the text lands, the mic icon is replaced by the send button and dictation cannot be resumed without clearing or sending.
2. Separately, later dictation attempts within the same session can fail outright. In one recorded case the "Speak to Claude, then press CAPS LOCK to stop" banner appeared, the Caps Lock indicator lit, then the banner dismissed after roughly three seconds with no text inserted and no error shown.

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" />

Sixth confirmation. macOS desktop app, Chat surface.

Both triggers reproduce here on the same machine: a pasted image removes the control, and so does plain typed text.

One data point I have not seen in the thread yet. The two surfaces inside the same desktop application do not behave the same way. The Code tab keeps the voice control visible and usable when the composer already holds text or an attachment. The Chat tab does not. Same application, same window, same width, opposite behaviour.

That is worth separating from the general layout question, because it means the desired behaviour is not hypothetical and does not need to be designed. It is already implemented and already shipping in the same binary, one tab across. Whatever the Code composer is doing with its control slot is what the Chat composer should be doing.

It also reinforces the point made above about the mobile idiom. If the swap were driven by available width, both tabs would swap at the same width. They do not.

Seventh confirmation, and a newer build than any reported so far.

Environment: Claude desktop app for Windows, version 1.46388.4.0 (MSIX). Chat surface.

Both triggers reproduce: the mic control is removed when a file is attached, and equally when the composer merely contains typed or dictated text. The issue is therefore still present several releases after 1.40609.0, which is the newest build confirmed earlier in this thread.

Adding a use case, since the thread has focused on the mechanics. I run a small e-commerce and automation business and I compose almost every message by voice, in Spanish. My normal pattern is: dictate a paragraph, attach a screenshot or a log file, dictate the explanation that goes with it, re-read, fix a word, keep going. Every single step after the first one is now blocked. The message that accompanies an attachment is exactly the message that most needs dictating, because it is the one that explains what the file is.

The Win+H workaround does insert text into a non-empty composer, but it uses the Windows speech engine. For Spanish the transcription quality is clearly worse than Claude's own, so it is not an equivalent fallback for non-English users.

On the "invalid" label: it was applied by the auto-labeler, not by a human triage pass, and it is wrong. Nothing fails at runtime here — the control is simply not rendered. It is a UI regression in the Chat composer, and as noted above the Code tab in the same binary already renders it correctly with a non-empty composer, so the fix does not need to be designed from scratch. Please could someone re-triage this off the invalid label.

Confirming this same issue still exists on macOS Tahoe Version 26.6.2 (25G83) using Claude desktop app version 1.52386.6 (612f3f).

My trigger is specifically the attachment case in the original report: if I paste or attach an image or file into the composer before using the microphone, the mic control never appears at all. It's not that it disappears after use, it's simply not there to begin with once something is attached.

My normal workflow is voice-to-text for everything, so this fully blocks messages that need an attachment plus spoken context. The only workaround I've found is dictating first and attaching second, which isn't always practical if the attachment is what prompts the message.

Agreeing with the comments above that this is a UI regression in the composer, not a transcription/speech-pipeline issue, and that the "invalid" label appears to have come from the auto-labeler rather than a human review. Would appreciate a re-triage.

Two updates that have minimized the issue for me:

1) In Browser (Chrome for Windows): For the past week it has NOT been timing out after 15 seconds, but goes on and times out after 60 seconds. I still am running into the problem were if there is text or a file in the chat, I can't dictate. But at least with text it is easy to cut and paste it back in.

2) On Desktop (Windows): In the last couple of days (not as early as in browser), the timing out also increased to 60 seconds. HOWEVER, in the Desktop I am using the tip to press "ctrl" + "d" and it turns the dictation back on even with text or a file, making it easy to use.

For my particular use cases, this is the difference between being able to openly dictate, and having to rely on run-on sentences. For others who want to just keep the dictation open, I can understand the problem remains particularly large.

The issue persists on Windows 11 with Cloud Desktop, version 2.16120.0.

Still reproducing on macOS, Claude Desktop

The issue is fixed for me now 🙂 on Windows (Claude Desktop version 2.31226.0).

I started having this issue 10/8 on version: Claude 2.31226.0 (eb794d) 2026-10-08T05:55:02.000Z

16\. I started having this issue 10/8 on version: Claude 2.31226.0 (eb794d) 2026-10-08T05:55:02.000Z

Same for me.

Since this still is not fixed, I found a workaround: Press Ctrl + D to activate the Mic even when the icon is not show.