[BUG] Spacebar spam on quick reactivation of voice mode push-to-talk

Resolved 💬 1 comment Opened Mar 31, 2026 by DrAlexHarrison Closed Apr 8, 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?

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

  1. Enable voice mode with /voice
  2. Hold spacebar to record a short phrase, release to process
  3. While the waveform shows "processing" (gray text finalizing), immediately hold spacebar again
  4. Observe: many space characters appear in the input before the second recording starts
  5. 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_THRESHOLD for instant re-activation on idle.
  • Deliberate presses (>120ms gaps): gap timer resets count to 0, normal typing behavior on idle — preserves #37020 fix

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗