Voice push-to-talk requires double /voice toggle on session start (regression from v2.1.70 fix)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30658
2. https://github.com/anthropics/claude-code/issues/33354
3. https://github.com/anthropics/claude-code/issues/32558

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is a duplicate of #32558 but I suggest keeping this one since its the best

I also tried rebinding to different keys then space but then I could not get voice mode to work at all

Title: Push-to-talk key handler never fires on Intel Mac — zero key events in debug log (v2.1.74)

Environment:

• Claude Code: v2.1.74 (native binary, x86_64)
• macOS: 26.3.1 (Build 25D2128)
• CPU: Intel Core i9-9880H (x86_64, not Rosetta)
• Terminals tested: Terminal.app (Apple_Terminal) and iTerm2 3.6.9
• Shell: zsh

Description:

Push-to-talk does not work at all on Intel Mac. The double /voice toggle workaround described in the original issue does not fix this on x86_64.

The native audio module loads successfully, and startRecording is called at /voice toggle time, but no key press events are ever detected for push-to-talk — regardless of keybinding.

Debug log evidence:

[voice] audio-capture-napi loaded in 454ms
[voice] startRecording called, platform=darwin

After this, zero voice-related entries when pressing/holding any push-to-talk key. No stopRecording, no transcription attempts, no "no speech detected" — nothing.

Keybindings tested (all produce zero events):

• space (default)
• alt+space
• ctrl+shift+z
• ctrl+shift+space
• f5
• ctrl+/

Keybindings load correctly per debug log:

[keybindings] Loaded 6 user bindings from /Users/digora/.claude/keybindings.json
[keybindings] Reloaded: 112 bindings, 0 warnings

Steps to reproduce:

1. Intel Mac with native binary v2.1.74
2. "voiceEnabled": true in ~/.claude/settings.json
3. Start claude, run /voice twice (off → on)
4. Hold Space (or any rebound push-to-talk key)
5. Expected: recording indicator appears, audio captured
6. Actual: Space types a space / other keys do nothing. Zero voice key events in --debug log.

Settings:

{
  "voiceEnabled": true
}

Keybindings:

{
  "bindings": [{
    "context": "Chat",
    "bindings": {
      "alt+space": "voice:pushToTalk",
      "ctrl+shift+z": "voice:pushToTalk",
      "ctrl+shift+space": "voice:pushToTalk",
      "f5": "voice:pushToTalk",
      "ctrl+/": "voice:pushToTalk"
    }
  }]
}

Key difference from original report: The double /voice toggle workaround works on Apple Silicon (#33378 OP) but does not work on Intel x86_64. This may be an architecture-specific regression in the native binary's key event handling.

Seeing the same behavior on Linux (Pop!_OS, kernel 6.18.7, Ghostty terminal) on v2.1.74.

• voiceEnabled: true in ~/.claude/settings.json
• On session start, space bar push-to-talk does nothing — just types spaces
• Running /voice once "wakes up" voice mode, after which space bar push-to-talk works normally
• Was working on the previous version (likely v2.1.73 or earlier)

So this isn't macOS-specific — same regression on Linux.

Follow-up: Still broken on v2.1.76 — Intel Mac, three terminals tested

Updated from v2.1.74 → v2.1.76 (native binary, x86_64). Same behavior — zero key events from push-to-talk.

Additional terminals tested since last comment:

• Terminal.app — no voice key events
• iTerm2 3.6.9 — no voice key events
• Ghostty — no voice key events

All three terminals have macOS microphone permission granted (confirmed in System Settings → Privacy & Security → Microphone).

New debug evidence (v2.1.76 session):

[voice] audio-capture-napi loaded in 473ms
[voice] startRecording called, platform=darwin

After these two lines — zero [voice] entries in the entire debug log. No stopRecording, no transcription attempts, no "no speech detected", no errors. The key handler simply never fires.

Additional verification performed:

• sox/rec installed and working — successfully records 1-second audio via rec /tmp/test.wav trim 0 1 (48kHz, 32-bit, CoreAudio input)
• claude auth refreshed — no change
• macOS system languages: en-RU, ru-RU (both supported)
• Keybindings reset to defaults (only shift+enter: chat:newline in custom keybindings.json), relying on default ctrl+/ — still no events

Environment:

• Claude Code: 2.1.76 (native binary, x86_64)
• macOS: Darwin 25.3.0
• CPU: Intel (not Rosetta)
• Terminals: Terminal.app, iTerm2 3.6.9, Ghostty
• Shell: zsh

This confirms the issue persists across versions (v2.1.74 → v2.1.76) and is not terminal-specific. Likely an architecture-specific (x86_64) regression in the native binary's key event handling, as noted in my previous comment.

Confirming this on Windows 11 + VS Code integrated terminal (Git Bash) across versions 2.1.72–2.1.76.

Analyzed 24 session JSONL files spanning March 11–14: 23 of 24 sessions show "Voice mode disabled." as the first /voice response, requiring the double-toggle workaround every time. The pattern is 100% reproducible.

Closing #34401 as a duplicate of this issue.

+1 for me
Environment:

• Claude Code version: 2.1.76
• macOS 15.7.3 (Build 24G416)
• Apple M3, 8 GB RAM
• Shell: zsh

Confirming on Linux (Ubuntu, kernel 6.8.0-106-generic) with v2.1.76.

• "voiceEnabled": true in ~/.claude/settings.json
• On session start, holding Space does nothing — must run /voice to activate
• Reproducible 100% of the time across sessions

Would love a voiceAutoStart or for voiceEnabled: true to actually auto-activate push-to-talk on session start as intended.

🤖 comment by Claude, edited by Alex.

Confirming on Macbook Pro M3 Max 48GB Tahoe 26.2, Claude Code v2.1.77

Same issue here on Windows 11 (10.0.26200) with Claude Code v2.1.77.

Every new session requires /voice → "Voice mode disabled" → /voice again → "Voice mode enabled" before spacebar PTT
works. voiceEnabled: true is set in settings.

This isn't macOS-specific, the platform:macos label should probably be removed or a platform:windows label added.

Edit: Resolved on version: 2.1.80

Confirming this bug persists in v2.1.79 (macOS Darwin 25.3.0), despite the release notes for both v2.1.75 and v2.1.79 claiming fixes for this exact issue.

The workaround remains the same: /voice off → /voice on at the start of every session.

Still experiencing this issue on v2.1.79 on Linux. Enabled globally true in settings and still requires the workaround.

Same as @SalzerRefinedLeads

UPDATE 2026-03-22: 2.1.81 fixes this on macos & linux for me.

Confirming on Macbook Pro M3 Max 48GB Tahoe 26.2, Claude Code v2.1.77

This has been resolved for my setup in 2.1.81

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.