Windows desktop: voice input opens healthy mic session but intermittently produces no transcription and no error

Summary

On the Windows desktop app (1.30096.5.0, MSIX package), clicking the mic opens a healthy microphone session that captures for the full spoken duration, but intermittently no transcribed text appears and no error is logged. Failure rate escalated over ~2 weeks to near-total in the last 2–3 days, closely tracking the 2026-08-14 update to 1.30096.5.0.

Timeline

• ~2+ weeks ago (baseline): first push of the mic button did nothing; a second push worked. Annoying but reliable.
• That held ~1 week, then recordings began silently producing nothing, unpredictably.
• Last 2–3 days (since the 2026-08-14 23:35 update to 1.30096.5.0 / move to MSIX): most attempts fail — roughly one successful transcription per several attempts, sometimes requiring a full app restart.
• Both views now affected: previously the plain Chat view (Home → chat) was a reliable fallback when dictation failed in the Code view; it now fails there too. A lighter-load view regressing suggests a shared main-process capture path degrading, not something specific to the coding agent.

Environment

• Windows 11 Pro 26200, 24-core desktop CPU, 64 GB RAM
• 2.4 GHz wireless USB headset (single physical capture device; a duplicate virtual "Microphone" device was disabled during diagnosis — not the cause)
• A separate desktop app with built-in dictation transcribes flawlessly on the same mic at the same moment → OS/mic/driver path is healthy

Key finding

A background monitor of the Windows mic-consent registry key (LastUsedTimeStart/LastUsedTimeStop) captured 4 consecutive failed attempts, each of which opened a healthy session that held for the full spoken time:

[20:57:37.549] BUTTON PUSHED  (mic session opened)
[20:57:41.193] RELEASED       (held 3.7s)
[20:57:48.980] BUTTON PUSHED  (mic session opened)
[20:57:52.752] RELEASED       (held 3.8s)
[20:57:58.509] BUTTON PUSHED  (mic session opened)
[20:58:03.154] RELEASED       (held 4.5s)
[20:58:10.369] BUTTON PUSHED  (mic session opened)
[20:58:18.782] RELEASED       (held 8.4s)

During that exact window the app logs contained no auth, transcription, or network errors — only, at each capture start:

[warn] The ScriptProcessorNode is deprecated. Use AudioWorkletNode instead.

plus recurring main-process stalls correlated with app activity:

[warn] [event-loop-stall] main process blocked for 1577ms / 1514ms / 3405ms ...

A failed dictation and a successful one are indistinguishable at the OS level; the only difference is whether text comes back. Success correlates strongly with the app being idle; any concurrent activity (streaming a response, running tools, warming sessions) raises the failure rate.

Ruled out during diagnosis

• Mic hardware/driver (ffmpeg dshow capture measured −6.0 dB max / −26.1 dB mean — clean speech; device healthy, ProblemCode 0)
• Windows mic permissions (global/app/packaged all Allow; Windows logged the app opening the mic)
• Default-device selection (correct mic default for all three roles)
• A transient Anthropic auth outage (503 auth_rpc_unavailable, ~30 min on 2026-08-16) broke dictation during its window but failures continue with auth healthy
• Chat model selection (fails identically on every model)

Suspected root cause

Mic audio is captured via ScriptProcessorNode, whose callback runs on the renderer main thread. When that thread stalls (rendering / tool execution / session warming — see event-loop-stall logs), sample buffers are silently dropped. The mic session stays nominally open (hence healthy OS-level sessions), but STT receives empty/near-silent audio and "successfully" returns an empty string — no error, no text.

Requested fix

1. Migrate mic capture to AudioWorkletNode (dedicated audio thread) — core fix.
2. Surface an explicit error when a transcription request contains empty/near-silent audio instead of silently returning nothing.
3. Investigate whether the 2026-08-14 (1.30096.5.0 / MSIX) change increased main-thread load or altered the capture path.

Repro

1. On the affected build, let the app do background work (several open sessions / any rendering or tool activity).
2. Click mic, speak a sentence, stop.
3. Session opens and closes normally; no text, no error.
4. Success rate rises sharply when the app is fully idle.