Voice: "No audio detected" in long-running session after default input device changes (macOS)
What happened:
In a terminal session that's been open a while, /voice fails with "No audio detected from microphone. Check that the correct input device is selected and that Claude Code has microphone access." The same /voice works immediately in a freshly opened terminal tab. The mic works fine in every other app at the same time.
This is the "recording opened but captured silence" case — distinct from No speech detected (transcription receives audio but no words) and from the missing-entitlement bugs (recording never starts, no TCC entry).
Root cause (confirmed):
The native audio module reads the system default input device once at session start and does not re-read it when the default changes. When the default input device changes mid-session, the long-running process keeps recording from the old (now-silent) device → silence captured → "No audio detected." A freshly spawned process picks up the current default, which is why a new tab works.
Confirmed deterministic repro (no Bluetooth/sleep needed):
- Open a terminal,
/voice→ works. - System Settings → Sound → Input → switch the default input device to a different one.
/voicein the same session → "No audio detected from microphone."- Open a new tab →
/voiceworks again.
Originally noticed via AirPods / Bluetooth connect-disconnect and sleep/wake, which trigger the same default-device change.
Expected:
Voice queries the current system default input device on each recording, so it keeps working after the default input device changes mid-session.
Environment:
- macOS 26.3.1 (build 25D2128)
- Terminal: Warp 0.2026.05.27.15.44.01
- Claude Code 2.1.162
- Microphone TCC permission granted to Warp; mic confirmed working in other apps concurrently.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗