[BUG] Windows desktop 1.37937.3.0 (MSIX): voice dictation broken after overnight auto-update — mic capture is killed after 0.1 s (manifest lacks microphone capability)

Summary

Voice dictation is completely broken since the overnight auto-update to 1.37937.3.0 (Windows, MSIX-packaged app). Clicking the mic opens an audio capture that the OS closes after 0.1 s, every time, with no visible error — the mic icon briefly turns red, then nothing. Dictation worked the day before; the update installed at 04:04 the same night, and nothing else changed on the machine.

Environment

• App: Claude desktop 1.37937.3.0, MSIX package Claude_1.37937.3.0_x64__pzs8sxrjxfjjc (auto-updated 2026-08-27 04:04:44, folder creation time)
• OS: Windows 11 25H2, build 10.0.26200 — no Windows updates since 2026-08-16 (KB5121003)
• Mic: Intel Smart Sound "Microphone Array" (the only active capture device), works in Chrome, OBS, Windows Voice Access, Word — everything except the Claude app

Objective measurement

Windows tracks per-app capture sessions in the registry (CapabilityAccessManager\ConsentStore\microphone\Claude_pzs8sxrjxfjjc). On every attempt:

LastUsedTimeStart : 14:12:53.7
LastUsedTimeStop  : 14:12:53.8   → capture lifetime 0.1 s

So getUserMedia succeeds (consent granted, stream opens) and the stream dies ~100 ms later.

What was ruled out (each verified by re-measuring the capture lifetime)

• Windows consent: Allow at all levels (global, desktop apps, and the per-package entry); also cycled Deny→Allow — no change
• Device selection: switched from "Default" to the explicit device entry — no change
• Push-to-talk: disabled ("Maintenez pour enregistrer" off) — no change
• Full app restart with volatile cache purge (Cache 351 MB, Code Cache 310 MB, GPUCache, Dawn*) — no change
• No other process holding the mic (no Voice Access/OBS running); speaker-side audio irrelevant
• Same-machine control group: Chrome (same Chromium capture stack) records fine

Possibly related packaging detail

AppxManifest.xml of the installed package declares only:

runFullTrust, localSystemServices, packagedServices, unvirtualizedResources, internetClient

— no microphone DeviceCapability. Windows nevertheless brokers this app per-package (it has its own ConsentStore entry, not the NonPackaged one), so on recent Win11 builds the brokered capture may be shut down at OS level for a package that doesn't declare the capability. This would exactly produce "stream opens, dies in 0.1 s, no app-level error".

Expected

Clicking the mic records and transcribes, as it did before 1.37937.3.0.

Actual

Capture closes after 0.1 s on every attempt; mic icon flashes red; no transcription, no error message.