[BUG] voiceEnabled: true requires double /voice toggle every session

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?

When voiceEnabled: true is set in ~/.claude/settings.json, every new session requires typing /voice twice before voice input works:

1. First /voice → "Voice mode disabled."
2. Second /voice → "Voice mode enabled. Hold Space to record."

Only after the second toggle does Space-to-record actually function. This happens every session — the setting never results in voice being usable at startup.

Root Cause Analysis

voiceEnabled: true sets an internal boolean to true at startup but does not initialize the audio pipeline. The UI considers voice "on" but the recording subsystem is not wired up. The first /voice flips the boolean to false (displaying "disabled"). The second /voice flips it back to true AND initializes the audio pipeline (displaying "enabled" with functional recording).

This is a state synchronization bug — the setting controls the flag but skips initialization.

Evidence from Session JSONL

Analyzed 24 sessions spanning versions 2.1.72 through 2.1.76:

• 23 of 24 sessions show "Voice mode disabled." as the first /voice response
• Always in toggle pairs: 2 toggles (disabled→enabled), 4 toggles, never odd
• Consistent across 5 versions: 2.1.72, 2.1.73, 2.1.74, 2.1.75, 2.1.76
• 4-day date range: March 11–14, 2026 — every single session

Example from session JSONL (2026-03-14):

16:29:35.089Z  /voice command sent
16:29:35.107Z  "Voice mode disabled."
16:29:37.578Z  /voice command sent
16:29:37.705Z  "Voice mode enabled. Hold Space to record."

The one session where the first toggle said "enabled" likely had voiceEnabled: false at that time, meaning the toggle correctly activated it on the first try — which is the expected behavior when the setting is false.

What Should Happen?

When voiceEnabled: true is set in settings, voice mode should be fully initialized and functional at session startup — no /voice toggle required. Alternatively, if the setting only controls whether /voice is available (not auto-start), the first /voice should enable it (not disable it).

Steps to Reproduce

1. Set "voiceEnabled": true in ~/.claude/settings.json
2. Start a new Claude Code session (in VS Code terminal)
3. Type /voice
4. Observe: "Voice mode disabled." (unexpected — should be "enabled" or already active)
5. Type /voice again
6. Observe: "Voice mode enabled. Hold Space to record." (now functional)

Claude Model

Opus

Is this a regression?

I don't know — voiceEnabled has always behaved this way for me.

Claude Code Version

2.1.76 (reproduced on 2.1.72, 2.1.73, 2.1.74, 2.1.75, 2.1.76)

Platform

Claude.ai (Max subscription)

Operating System

Windows 11 Home 10.0.26200

Terminal/Shell

VS Code integrated terminal (Git Bash)

Additional Information

Settings file (~/.claude/settings.json) contains:

{
  "voiceEnabled": true,
  "alwaysThinkingEnabled": true,
  "showThinkingSummaries": true
}

No .claude.json GrowthBook cache file exists in ~/.claude/. The tengu_amber_quartz feature flag appears to be enabled (voice is accessible, just requires the double-toggle workaround).

Native audio modules are being extracted to %TEMP% as .node files (~492KB each), suggesting the audio-capture.node bundling fix from #30915 is working on this version.