[BUG] Spacebar spam on quick reactivation of voice mode push-to-talk
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 using hold-to-talk voice mode, completing one recording and immediately re-pressing spacebar to start a second recording causes dozens of space characters to appear in the input before the second recording activates.
The state machine goes recording → processing → idle. During the processing window (~0.5-3s), rapid spacebar presses flow through to the text input because isHoldActiveRef was reset when state left recording. When state reaches idle, rapidCountRef is also zero, so the full HOLD_THRESHOLD (5 presses) warmup restarts from scratch — leaking 2 more warmup spaces plus all the spaces from the processing window.
This makes sustained voice-driven workflows painful. The user's intent when rapidly re-pressing space after a recording is clearly to re-activate voice, not to type spaces.
What Should Happen?
At most 1-2 spaces should appear between consecutive voice sessions. Rapid spacebar presses during processing state should be suppressed (since the user can't meaningfully type while waiting for transcription) and counted toward the hold threshold so voice re-activates immediately when processing completes.
Error Messages/Logs
No errors — behavioral bug. The spaces are visible in the prompt bar input field.
Steps to Reproduce
- Enable voice mode with
/voice - Hold spacebar to record a short phrase, release to process
- While the waveform shows "processing" (gray text finalizing), immediately hold spacebar again
- Observe: many space characters appear in the input before the second recording starts
- The longer the processing takes, the more spaces accumulate
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.79
Claude Code Version
2.1.87 (Claude Code)
Platform
Other
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Related: #37020 (the opposite bug — spaces swallowed during processing). The fix for #37020 created this one. Both bugs can be fixed simultaneously by using RAPID_KEY_GAP_MS (120ms) as the discriminator:
- Rapid presses (<120ms gaps, auto-repeat pattern): suppress during processing, accumulate toward
HOLD_THRESHOLDfor instant re-activation on idle. - Deliberate presses (>120ms gaps): gap timer resets count to 0, normal typing behavior on idle — preserves #37020 fix
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗