[BUG] Voice mode spacebar swallowed during processing after release (regression in 2.1.81)

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?

After releasing the space bar from push-to-talk recording, the space bar is captured/swallowed during the Speech-To-Text (STT) processing/finalization window (~0.5s after speaking, up to ~3s if no speech was detected, in my exp.). All other keys work normally — only the space bar is blocked during processing.

This creates two slightly frustrating scenarios, the second worse than the first:

1. Spoke, then released to type: The space bar is blocked for ~0.5s while the transcript finalizes (gray text → white text). You can type letters but not spaces during this window.

1. Held Space but decided not to speak, released to type instead: The space bar is blocked for up to ~3 seconds while it tries to determine whether speech occurred. This is the worse variant. It's the case where I've actually decided to not engage with voice mode and thought to myself "I'll actually be better at typing this." In irony, it steals my ability to type accurately at that very moment by not registering space bar key presses as characters in the terminal.

Itlookslikethisandisinfuriating.

The ~3-second delay in the no-speech case seems to happen because the system detects ambient audio (fans, AC, etc.) and interprets it as "maybe there was speech" — then retries processing before giving up. This retry adds ~2-3 extra seconds even when I clearly didn't speak. It seems like a simpler check would be whether any speech was actually recognized — if nothing was transcribed, retrying the same audio is unlikely to help.

In prior versions (≤2.1.80), releasing the space bar immediately returned it to normal text input. STT processing happened in the background without blocking the space bar. All key presses registered as characters, including space bar producing " ".

What Should Happen?

Preferred solution — Free the space bar during voice processing!

• Only block Space while actively recording — once I release the space bar, it should go back to typing spaces immediately, even if the transcript is still finalizing
• Don't retry (or limit retries harder) when no speech was recognized — ambient noise alone shouldn't cause a multi-second delay
• If re-activation is a concern, block rapid triple-tap (3+ presses with <120ms gaps) rather than blocking all space input during finalization

Releasing the spacebar should immediately return it to normal text input, as it did in versions prior to 2.1.81. The transcription finalization (gray → white transcript) should continue in the background without blocking registry of spacebar events. While underlying logic to block this laid latent behind another bug, that bug inadvertently allowed substantial testing of a more liberally-released space bar logic, which in my experience was the preferred user experience with no hiccups.

It seems like Space is being blocked during both the recording phase AND the post-release finalization phase. Since I've already released the key, blocking it during finalization is unnecessary and frustrating. Letting Space pass through as normal text input while the transcript finalizes in the background would match the behavior I experienced in 2.1.80.

If needing safeguards during processing to prevent rapid space key hit logic the logic that rapid space key actions my personal preference would be to block space bar hits past two in sequence where the gap between each is <=120ms. That would allow for excited post-speech typing without risk.

Alternative (less preferred)

If there's a reason to block the spacebar during processing, then all character-producing key presses should be blocked too, to avoid the "nonsense cleanup" problem where only spaces are missing from otherwise normal typing. Currently, all other keys pass through freely during processing. Blocking only Space is inconsistent. It also makes for many-key-presses-needed cursor navigation to within a long string of non-space chars.

Error Messages/Logs

No error messages. The space bar key press is silently swallowed — no visual indicator that it's still captured. The only signal that the space bar has been returned is observing the transcript text change from gray to white and that as you type words it no longerlookslikethis and you see spaces appearing again like this.

Steps to Reproduce

In Claude Code

Variant 1 (spoke, then released):

1. Enable voice mode (/voice or voiceEnabled: true)
2. Hold space bar and speak a sentence
3. While holding, observe gray interim transcript streaming word-by-word
4. Release space bar — transcript remains gray briefly, cursor returns to normal terminal color
5. Immediately try to type a sentence including spaces
6. Letters appear but spaces do not register for ~0.5s until the transcript turns from gray to white

Variant 2 (held Space, decided not to speak):

1. Enable voice mode
2. Hold space bar as if to speak (rainbow cursor appears)
3. Decide not to speak — release space bar to type instead
4. Try to type — spaces do not register for up to ~3 seconds while STT runs retries on ambient noise.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.80

Claude Code Version

2.1.81 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment details:

Linux Mint 22.3 (Ubuntu 24.04 noble), kernel 6.8.0-106-generic, GNOME Terminal, bash, PipeWire 1.0.5

Why this appeared in 2.1.81

This regression is a side effect of the voice-enabled startup initialization fix (#34012). Prior to 2.1.81, voice mode didn't properly initialize on startup even when voiceEnabled: true was set — you had to toggle /voice off and on. Because voice wasn't activating, the Space-blocking-during-processing behavior never had a chance to trigger.

The 2.1.81 fix made voice mode work on startup (yay!), but that also meant the Space-blocking-during-processing logic ran for the first time. So this isn't a new bug — it's a latent behavior that was previously masked by the startup initialization bug.

Two contributing factors

Factor 1 — Space blocked during processing (latent, now exposed):
Space is blocked during the entire time voice mode is doing anything — not just while recording, but also during the finalization window after release. In 2.1.80, this couldn't trigger because voice didn't initialize properly (see above).

Factor 2 — Retry on ambient noise extends the blocking duration:
When I don't speak but ambient noise is present (fans, AC — pretty much any room), the system seems to think "maybe there was speech" and retries before giving up. This extends the space-blocking window from ~0.5s to ~3s. In a quiet room it's brief; in a normal room with any background noise, it's painfully long.

This timing coincides with the changelog item "Fixed voice mode audio not recovering when the server silently drops the WebSocket connection" — the retry logic for dropped connections may also be firing on ambient-noise-only sessions.

Visual behavior

Before the bug

• Holding Space: Rainbow-morphing cursor, and if speaking, then gray interim transcript streams word-by-word (~3-4 words per chunk at normal pace)

During the bug

• On release: Cursor immediately returns to normal terminal color (gray). Transcript stays gray momentarily.
• On transcript finalization:
• ~0.5s after spacebar release (or ~2-3s, if no speech): Transcript turns from gray to white, if there is any transcript. Spacebar becomes available again. If no transcript, no visual change.
• No visual cursor-based state-change indicator that the spacebar has been returned to normal input — only the gray→white text color change.
• Primary visual indicator of bug is textthatlookslikethis when you start typing before the spacebar has been released from its intra-processing hold.

Previous behavior (≤2.1.80): Spacebar was immediately available for typing on release. The gray→white finalization happened in the background without blocking any keys.