[BUG] Web/desktop composer: mic button disappears when text is present, so interrupted dictation cannot be resumed
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?
Related: #90117 (text variant, macOS desktop), #90159 (attachment variant, Windows desktop), #74534 (the silence timeout this interacts with)
This report consolidates both variants and adds: reproduction on claude.ai web in a browser (not just the desktop app), screenshots of all states, an iOS comparison showing the current mobile composer rendering mic and Send together with content present, and the measured interaction with the new silence auto-stop.
Environment
- claude.ai web, current Chrome, Windows 11
- Identical behavior in the Windows desktop app (current version)
- Started within the past week; reproduces every time
- Not present in the iOS app (current version, tested today)
Description
Once dictation puts text in the composer, the mic button is gone entirely. Not disabled or unresponsive — absent. It only returns when the composer is empty, either by deleting all text or by submitting the prompt.
So there is no way to start dictation when text is already in the box, which means a dictation session that ends (manually, or via the silence auto-stop) cannot be resumed by voice. Every prompt has to be captured in one unbroken take.
In addition, once a file has been uploaded, there is no option to dictate, so any instructions need to be typed, or dictated before any uploads.
Why this matters
This interacts badly with the silence auto-stop that now applies to web/desktop composer dictation (measured at roughly 17-18 seconds after last speech; see #74534). The timeout cuts long prompts off mid-thought, and this bug then blocks resuming by voice. Together they cap every dictated prompt at a single continuous take with no pauses. I have caught myself padding my speech with filler just to keep the mic alive.
The iOS app currently has neither problem, so this is a regression relative to Claude's own dictation behavior, not a platform-wide constraint.
Screenshots
SCREENSHOT 1 - Before Dictating
<img width="1652" height="428" alt="Image" src="https://github.com/user-attachments/assets/201256c2-592a-4c42-8b50-16b9a0fe6785" />
SCREENSHOT 2 - While Dictating
<img width="1618" height="206" alt="Image" src="https://github.com/user-attachments/assets/20294845-f02a-4a43-8066-86fae6dd0955" />
SCREENSHOT 3 - After Dictating and no option to resume
<img width="1594" height="316" alt="Image" src="https://github.com/user-attachments/assets/2fe4b229-b454-4076-a57f-2405f806f3ab" />
SCREENSHOT 4 - After Dictating on the iPhone App
<img width="1290" height="1763" alt="Image" src="https://github.com/user-attachments/assets/ebc3a68f-7b30-4876-a12e-91ae45756124" />
What Should Happen?
The mic stays available while text is present, and starting dictation again appends to the existing text. This is how the iOS app behaves today: tested on the current version, I can stop and restart dictation with text already in the box and keep appending.
Error Messages/Logs
Steps to Reproduce
- On claude.ai web, click the mic to start dictation
- Speak, then stop dictation (or wait for the silence auto-stop)
- The transcript appears in the composer
- Observe: the mic button no longer exists anywhere in the composer
- Delete all text in the composer: the mic returns
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
N/A - not a CLI bug. claude.ai web (current) and Windows desktop app (current).
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_