Voice input leaks Space characters on Linux in v2.1.83 (regression from 2.1.81)

Description

Voice input (hold-to-talk with Space) is broken in v2.1.83 on Linux. The keybind partially fires — cursor changes color indicating voice mode activates — but:

1. Space characters are inserted into the input box continuously (as if Space is held as a regular keypress)
2. No audio is captured / no transcription occurs
3. The cursor "runs off" to the right filling the input with spaces

Reverting to 2.1.81 (via symlink) fixes the issue completely — voice works normally.

Environment

• OS: Ubuntu 24.04 (Linux 6.17.0-14-generic)
• Hardware: Lenovo Yoga 6, AMD Ryzen 7 5000
• Audio: PipeWire 1.0.5, ALC285 analog mic + digital mic (both working)
• Terminal: GNOME Terminal (not SSH/remote)
• sox: installed (/usr/bin/sox)
• pactl: installed (/usr/bin/pactl)
• Node: v20.19.0
• Install method: Native installer (~/.local/bin/claude symlink)

Steps to Reproduce

1. Fresh install or update to v2.1.83 on Linux with PipeWire
2. Enable voice: /voice
3. Hold Space to dictate
4. Observe: cursor changes color but spaces fill the input box, no audio captured

Expected Behavior

Space should be intercepted by voice mode, audio should be recorded, and transcription should appear in the input box (as it does in 2.1.81).

Workaround

Downgrade to 2.1.81:

ln -sf ~/.local/share/claude/versions/2.1.81 ~/.local/bin/claude

Possibly Related

v2.1.83 changelog mentions:

• "Fixed a 1–8 second UI freeze on startup when voice input was enabled, caused by eagerly loading the native audio module"
• "Fixed space key being swallowed for up to 3 seconds after releasing voice hold-to-talk"

The lazy-loading change to the native audio module may have introduced a race condition where Space keydown fires before the audio module is ready to intercept it, causing it to fall through to the text input handler.

🤖 Generated with Claude Code