Voice: "No audio detected" in long-running session after default input device changes (macOS)

Resolved 💬 2 comments Opened Jun 4, 2026 by oleksiidonetskyi Closed Jun 25, 2026

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):

  1. Open a terminal, /voice → works.
  2. System Settings → Sound → Input → switch the default input device to a different one.
  3. /voice in the same session → "No audio detected from microphone."
  4. Open a new tab → /voice works 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗