[BUG] Windows desktop (MSIX 1.49585): dictation captures audio but returns no text; works only while another app holds the microphone open

Summary

In the Windows desktop app, the in-app voice dictation (microphone button in the chat composer) captures audio from the microphone but never returns any text. The same dictation works reliably as soon as another process is holding the same capture endpoint open (e.g. the "Test your microphone" meter in Windows Settings > System > Sound > Input). Close that page and dictation stops producing text again.

This "works only while another client holds the endpoint" detail does not appear in the existing reports (#59849, #72469, #71764), so I am filing it separately in case it helps narrow the cause.

Environment

• Claude desktop app 1.49585.0.0, Microsoft Store package (Claude_pzs8sxrjxfjjc, MSIX)
• Windows 11 Home 10.0.26200 (25H2), desktop PC
• Microphone: Razer BlackShark V2 HS 2.4 (wireless USB dongle). It is the only active capture endpoint. Razer Central / THX Spatial Audio software components are installed.
• Language: French

Steps to reproduce

1. Make sure nothing else is using the microphone.
2. In the desktop app, click the microphone button in the composer, wait ~3 s, then speak clearly for ~7 s, stop.
3. Nothing is inserted in the composer.
4. Open Windows Settings > System > Sound > Input > the Razer microphone, so the level meter is running.
5. Repeat step 2: the spoken text is transcribed and inserted normally.

Evidence that audio capture does happen

Windows' microphone consent store (HKCU\...\CapabilityAccessManager\ConsentStore\microphone\Claude_pzs8sxrjxfjjc) records each access by the app. For the failing attempt in step 2, LastUsedTimeStart / LastUsedTimeStop show a 9.5 s capture session (earlier attempt: 3.8 s). So the app is granted the microphone and does open it for the whole time the user speaks; the failure is downstream of capture (silent samples, or transcription).

What works / what was ruled out

• Microphone privacy: Windows (global), desktop apps, and the Claude package are all Allow.
• The same microphone works in Chrome (including claude.ai dictation in the browser), Discord and other apps.
• Already tried without effect: disabling audio enhancements on the endpoint, disabling USB power management on the headset dongle, waiting several seconds after starting dictation before speaking (the 9.5 s session above), restarting the app.
• Reinstalling was not attempted because the direct download is now the same MSIX package.
• %APPDATA%\Claude\logs\*.log stop on 2026-08-21, so there is no recent log to attach; happy to enable/collect logs if you tell me where they are written now.

Possible angle

Whatever differs when a second client already has the endpoint open (audio engine already running with the endpoint's shared-mode format/period, APO chain already initialised) seems to be what the app's capture path needs. A wireless headset endpoint that reports silence until the engine is running, combined with the app opening the stream as the first client, would match the symptom.

Workaround

Windows built-in voice typing (Win+H) into the composer, as reported in #59849.