[BUG] Voice mode silently captures no audio in 2.1.148 (accessibility regression)

Resolved 💬 4 comments Opened May 22, 2026 by Cfeusier Closed Jul 7, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Push-to-talk voice mode in Claude Code 2.1.148 on macOS captures no audio. The audio-capture-napi native binding loads successfully but produces zero audio frames over a 10-second hold. The UI surfaces a misleading "Voice connection failed. Check your network and try again." error — the underlying failure is not network-related. The TUI input freezes for at least 10 seconds before I can enter any input.

This is an accessibility regression for me — voice mode is how I primarily interact with Claude Code due to a typing difficulty. It worked normally until ~2 days ago. I have not changed my system configuration; macOS auto-updates are disabled.

What Should Happen?

Voice control input should work as expected: holding the space key should capture audio and transcribe to text.

Error Messages/Logs

04:37:28.077 [voice] handleKeyEvent: idle, starting recording session immediately
  04:37:28.293 [voice] audio-capture-napi loaded in 215ms
  04:37:28.294 [voice] startRecording: buffering audio while WebSocket connects
  04:37:28.294 [voice] startRecording called, platform=darwin
  04:37:38.603 [voice] No auto-repeat seen, arming release timer via fallback
  04:37:38.608 [voice_stream] Connecting to wss://api.anthropic.com/api/ws/speech_to_text/voice_stream?...
  04:37:38.823 [voice] finishRecording: stopping recording, transitioning to processing
  04:37:38.823 [voice] Recording stopped
  04:37:38.824 [voice] Final transcript assembled (0 chars): ""
  04:37:39.516 [voice_stream] WebSocket connected
  04:37:39.518 [voice_stream] Sending initial KeepAlive
  04:37:39.520 [voice_stream] WebSocket closed: code=1000 reason=""

Steps to Reproduce

  1. Launch claude --debug with CLAUDE_CODE_DEBUG_LOGS_DIR set
  2. Trigger push-to-talk and hold for ~3 seconds
  3. UI freezes for ~10s, then displays "Voice connection failed"

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.139

Claude Code Version

2.1.148

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment Notes

  • macOS: Darwin 25.3.0 (Apple Silicon)
  • Terminal: reproduced in both Zed terminal and Terminal.app
  • Microphone permission: granted to terminal apps
  • Input Monitoring: terminal apps present in allowlist
  • ApplePressAndHoldEnabled = 0, key-repeat settings normal

Observations

  • audio-capture-napi loads with no error, but no audio frames or errors are logged during the 10-second hold.
  • The "No auto-repeat seen" fallback path is what eventually ends the recording — the user-facing intent (release on key-up) isn't reached.
  • The WebSocket only begins connecting after the 10-second fallback fires, so by the time it connects there's nothing to send. The closure with code 1000 is a clean close, not a network failure — making the surfaced "Voice connection failed. Check your network" message misleading.

What I've already ruled out

  • Network / Cloudflare (claude.ai loads in browser; WebSocket actually connects when it tries)
  • Auth (re-login, restart, fresh session all attempted)
  • Terminal emulator (reproduced in Zed terminal and Terminal.app)
  • macOS Microphone / Input Monitoring permissions (granted)
  • macOS press-and-hold and key-repeat settings (defaults are correct)
  • Vim mode (toggled off, no change)

Ask

Given this is an accessibility regression for me — flagging for priority. Happy to provide full debug logs, run any additional diagnostics, or test pre-release builds.

Thank you

View original on GitHub ↗

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