Voice dictation permanently reports "No audio detected from microphone" after input device invalidation (lid close on Apple Silicon) — #65331 regressed/incomplete

Environment

• Claude Code 2.1.204 (native install, stable channel), macOS 26 / Darwin 25.5.0, Apple Silicon MacBook Air
• Terminal: cmux 0.64.19 (mic TCC grant confirmed for the terminal; dictation works in fresh sessions so permissions are fine)
• Claude.ai account auth; voice settings: {"enabled": true, "mode": "hold"}

Symptom

• Hold-space dictation works in brand-new sessions. After the session's bound input device is invalidated mid-session, THAT session permanently shows: No audio detected from microphone. Check that the correct input device is selected and that Claude Code has microphone access. Recording appears to start (capture begins) but only silence is captured. New sessions started afterward work immediately. /voice off then /voice hold does not recover the broken session.

Deterministic repro — no device switching involved

1. Start an interactive session, enable /voice hold, dictate — works.
2. Close the MacBook lid with system sleep disabled (machine stays awake). On Apple Silicon, lid close hardware-disconnects the built-in microphone (documented Apple Platform Security behavior: "hardware microphone disconnect").
3. Reopen the lid — the built-in mic re-enumerates in CoreAudio.
4. Hold space in the pre-existing session → capture starts, records only silence → the error above. A fresh session works instantly.

Verified during repro: no AirPods/Bluetooth device ever connected (default input remained "MacBook Air Microphone" throughout, per system_profiler SPAudioDataType), and the machine never slept (pmset -g log shows no sleep entries; SleepDisabled 1).

Hypothesis

The native audio module resolves the default input device once at session start and keeps using that binding. Hardware disconnect/re-enumeration of the SAME physical device (lid close/open) invalidates the stale AudioDeviceID/AudioObjectID, so subsequent captures start against a dead device and yield silence. #65331 (closed completed 2026-06-25) covered default-device switches, but 2.1.204 still fails when the same device re-enumerates — either a regression or the fix doesn't re-resolve on capture start.

Related issues

• #65331 — same symptom on default input device change (closed completed, but persists on 2.1.204)
• #58160 — second concurrent session, identical error (closed not_planned)
• #52845 — duplicate of this family
• #72469 — open, audio stream teardown
• #71689 — open docs issue noting the troubleshooting page omits the device-change cause

Suggested fix

Re-resolve the default input device on every capture start (or subscribe to kAudioHardwarePropertyDefaultInputDevice / device re-enumeration events), and have the "No audio detected" failure path drop the cached device binding so the next attempt rebinds.