Cowork dictation stops ~2s after start on macOS Tahoe 26.4.1 — began immediately after auto-update to 1.15962.0 (039543); chat dictation unaffected
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?
Voice dictation in the Cowork/agent input cuts off roughly 2 seconds after I start speaking, even while I'm still talking. Cowork's own input level meter visibly registers my voice the whole time, so audio is reaching the recorder — but the recording session tears down at ~2s and stops capturing.
Reproducible via both the in-app microphone button and the keyboard shortcut, and in both hold and tap styles. The behavior is identical every time.
Dictation in the regular Claude chat box works perfectly on the same machine, same session, same mic — so this is specific to the Cowork audio/recording path, not the device.
This started immediately after Claude Desktop auto-updated to 1.15962.0 (039543) overnight. The prior build worked. I changed nothing else.
What Should Happen?
Holding (or tapping to start) dictation in the Cowork input should record continuously until I stop/release, transcribe my full speech, and insert the text — the same as the chat box dictation does on this machine.
Error Messages/Logs
No audio/mic/voice/transcription entries appear in ANY ~/Library/Logs/Claude/*.log file during the failure window. Verified with:
grep -riE 'audio|mic|voice|record|transcri|stream' ~/Library/Logs/Claude/*.log | grep -iE 'error|fail|denied|closed|stop|abort|empty|zero|null'
The only matches were unrelated: "stream-json" process spawns in coworkd.log, and rate_limit / "Tool permission stream closed before response received" entries in main.log. Nothing audio-related is logged when dictation drops — i.e. the failure produces no error in Claude's own logs.
[If you can add it: during the ~2s, does any text appear then stop, or does no text ever land? Note whichever you see — it distinguishes "session killed mid-stream" from "transcription never connected."]Steps to Reproduce
- Open Claude Desktop on macOS Tahoe 26.4.1, build 1.15962.0 (039543).
- Go to Cowork and click into the dictation input.
- Start dictation (mic button OR keyboard shortcut; hold or tap — all the same).
- Speak continuously for more than 2 seconds.
- Observe: the input meter registers voice, but recording stops ~2s in and capture ends, despite continued speech.
- For contrast: repeat in the regular chat box — dictation works normally.
Ruled out beforehand: mic permission granted to Claude Desktop (toggled off/on, app restarted); built-in mic set as system default with input level moving while speaking; sudo killall coreaudiod; full Mac restart.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact string — auto-replaced overnight by 1.15962.0. Worked on the immediately prior build; not recoverable from local logs.
Claude Code Version
1.15962.0 (039543) · SDK/CLI 2.1.187 · Node 24.16.0
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
- Chat-box dictation works on the same machine/session, isolating this to the Cowork audio path.
- Cowork's input meter shows live audio during the failure, so audio reaches the recorder — the session is being terminated downstream (~2s in), not starved of input.
- Timing implicates the build: dictation worked the day before, broke immediately after the overnight auto-update to 1.15962.0 (built 2026-06-25T01:24:19Z). No other changes. Restart and
killall coreaudioddid not help. - Possibly related to #55865 (Code-tab dictation discards transcript on stop, macOS Tahoe 26.4.1) — same OS and in-app dictation surface, but a different tab (Cowork vs Code) and a different failure mode (recording terminates ~2s mid-speech rather than discarding cleanly on stop). Suggests a per-tab in-app dictation regression on Tahoe.
- Anthropic Desktop auto-updates have a history of introducing Cowork regressions that needed follow-up patches, so a build-introduced regression here is plausible.
- No user-side mitigation found (permissions, built-in mic, coreaudiod restart, full reboot, key-hold, focus-in-field all tried). Workaround in use: chat dictation / system-wide dictation tool typed into the focused Cowork field.
Build: Claude Desktop 1.15962.0 (039543) · SDK/CLI 2.1.187 · Node 24.16.0 · macOS Tahoe 26.4.1 (Apple Silicon, MacBook Air)
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Same behavior confirmed... weirdly enough it does work for chat.
Same issue here — MacBook Air M1, macOS Sequoia, Claude Desktop 1.15962.0 (039543).
Dictation in Cowork stops ~2 seconds after starting, even while still speaking. The mic level meter shows audio is being captured the whole time. Dictation in the regular chat works perfectly on the same machine and session.
Tried: checking mic permissions, closing all other audio apps, signing out and back in, full uninstall and reinstall. None of these resolved it.
Confirming the issue is reproducible on M1 / Sequoia, not only on Tahoe.
Confirming on macOS — reproduces across multiple Apple Silicon devices, second dictation attempt fails
Adding a data point that spans both #71551 and #71764.
Environment: macOS, Claude Desktop 1.15962.0 (039543), tested on Mac Studio M2 and MacBook Air M4.
Behavior: Cowork dictation works correctly on the first use in a session — audio is captured and transcribed normally, same as chat. On the second dictation attempt within the same session, audio activates but terminates in under two seconds, with no transcription produced. This matches the failure mode in both linked issues.
What I ruled out: No changes to audio configuration, system settings, or hardware on either machine. Both devices exhibit identical behavior, ruling out a device-specific or hardware issue.
Regression timing: Working prior to the June 25 auto-update; broke immediately after. No other changes between the working and broken states.
The cross-device reproduction (M2 and M4, different machines) and the consistent "first use works, second fails" pattern suggest this is a session state or re-initialization issue in the Cowork audio path introduced by the June 25 build — not a platform or hardware regression.
Confirming this on macOS, Claude Desktop 1.15962.0 (039543). Same pattern @simplyspoke described: the first dictation in a fresh conversation works and transcribes normally, but every subsequent attempt in the same thread drops in under ~2s and won't recover — repeatedly pressing the mic button does nothing. Started suddenly with the June 25 auto-update; full quit/relaunch and "check for updates" did not help.
One additional data point: my input device is an Apple Studio Display Microphone (USB), not the built-in mic, so this is not specific to the built-in mic. System side verified healthy — mic permission ON for the app, input level registering in Sound → Input, standard 44,100 Hz / 24-bit format (Audio MIDI Setup), macOS Voice Control off, no other app using the mic. Consistent with a session re-initialization issue in the Cowork audio path rather than anything device- or OS-permission-related.
I can also confirm this occures with built-in mic, usb, and bluetooth, so strong evidence it is not system or device specific.
Confirming on macOS (Apple Silicon, MacBook Pro), Claude Desktop, Cowork. Same failure: Cowork dictation cuts off ~1s after I start, while I'm still speaking; the input-level meter shows my voice the whole time. Regular Claude chat and Claude Code dictation both work fine on the same machine and mic, so this is isolated to the Cowork audio path.
In my case it fails on every Cowork chat, including freshly created ones — not only the second attempt within a session. Tried with no effect: full quit & relaunch, updating to the latest build, explicitly selecting the built-in mic instead of "Default" in the picker, enabling push-to-talk, and starting new Cowork chats. Current workaround: macOS system dictation typed into the focused Cowork field.
This morning I woke up to the laptop which is the ARM processor exhibiting the same behavior apparently there was an update on the ARM processor to version 1.1596 2.1 I can't believe I'm the only one that has this problem then is anybody out there?
Also hitting this on macOS. Cowork voice dictation dies about 2 seconds after I start, the input meter shows my voice registering the whole time so audio is being captured, but nothing transcribes. Regular Claude chat dictation works fine on the same mic and machine, so it's specific to the Cowork path. Started after a recent auto-update. This is my primary way of using Cowork and having to hand-type everything is a serious hit to how usable the product is. Please prioritize, and please add an in-app bug report / known-issues surface so this doesn't only live on GitHub where most Cowork users will never look.
Confirming this on macOS Sequoia 15.7.5 (24G624), Apple Silicon — same symptom (Cowork voice cuts out ~1s after start, input meter shows audio the whole time; regular chat-box dictation works fine). Adding two things that may help narrow the root cause.
1. Still broken after two more updates. It did not get fixed by subsequent builds — reproduces on 1.15962.1 and now 1.17377.1. So whatever shipped after 1.15962.0 hasn't addressed it.
2. Candidate root cause: the Claude Desktop binary is missing the Speech Recognition entitlement. This may be the same underlying defect as the (now closed/locked) #52524. On my install:
Present:
com.apple.security.device.audio-input(this is why the chat-box mic works). Missing:com.apple.security.personal-information.speech-recognition. Consistent with the symptom — the chat path uses plain audio capture (works), while the Cowork/dictation path needs Speech Recognition and is silently denied (no TCC prompt, and Claude never appears in System Settings → Privacy & Security → Speech Recognition).Log signature at failure: repeated
kTCCServiceMicrophonerequests fire in a burst (acquire → drop → retry) and the helper's audio session goes inactive right after starting. Nothing audio-related is written to~/Library/Logs/Claude/*.log, matching what others reported here.Ruled out (no effect): mic permission granted, built-in mic pinned as default, removed Continuity/iPhone input, no other app using the mic, no hotkey conflict, full uninstall/reinstall, cleared caches.
If maintainers can confirm whether the Cowork dictation path routes through Speech Recognition, adding
com.apple.security.personal-information.speech-recognitionand re-signing (cf. prior regression #33023) looks like the likely fix. Related reports: #71764, #71887, #72284.I just restarted and it look like its working again!