[BUG] Voice tap mode: hard-coded 15s silence and 120s max-duration timers end the recording AND auto-submit the partial prompt, with no way to configure them

Status Open
Reported on v2.1.245
Maintainer reply None cached
Activity 0 comments · opened Aug 25, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

With "voice": { "mode": "tap" }, a dictation session can end by itself and then submit the half-finished prompt to the model, with no warning and no way to turn it off.

Two hard-coded timers are armed the moment a tap-mode recording starts:

if(o==="tap"){
  if(m==="idle") s("[voice] toggle: starting recording"), this.#g=!0, this.#I(), this.#$(), this.#q();
  else if(m==="recording") s("[voice] toggle: finishing recording"), this.#m();
  return
}
  • #$() — a 15 second silence timeout (jn = 15000), logging [voice] Toggle silence timeout — auto-finishing
  • #q() — a 120 second max-duration cap (zn = 120000), logging [voice] Toggle max-duration cap — auto-finishing

Both call #m() (finishRecording). The damaging part is what happens next — the transcript handler auto-submits in tap mode:

let I = (A === "tap" || w) && No(a) >= 3;
if (I) r.current?.submit(L, !0);

So the sequence is: you pause for 16 seconds to think, or you talk for two minutes straight; the recording silently ends; the partial transcript is inserted; and because it has 3 or more words it is sent to the model immediately. You lose the rest of what you were going to say, and you've now spent a turn on a truncated prompt.

Neither timer is configurable. The settings schema only exposes:

voice: { enabled?, mode?: "hold"|"tap", autoSubmit? }

and the only voice-related env vars in the binary are CLAUDE_CODE_REMOTE and CLAUDE_CODE_VOICE_FORWARD_INTERIMS_TYPED. Neither affects the timers. The only escape is to abandon tap mode for hold — where neither timer is armed, since both are guarded on the tap-mode flag #g — but that means physically holding a key for the whole utterance.

There is also no warning that it's about to happen. In tap mode the indicator just reads REC · tap to send the entire time, including the moment before it gives up.

(Possibly related but a different surface: #77823 describes dictation silently stopping in the chat-input mic button. This report is specifically about the CLI's tap mode and the auto-submit that follows the timeout.)

What Should Happen?

Primarily: a timeout should never submit. If the client decides on its own to end the recording, the transcript should be left in the composer for the user to finish, edit, or discard. Auto-submit should require the user's explicit tap.

Secondarily, the timers should be tunable and the 15s default is short for anyone composing a thought out loud.

Error Messages/Logs

No error is shown to the user. In the debug log:

[voice] Toggle silence timeout — auto-finishing
[voice] Toggle max-duration cap — auto-finishing

Steps to Reproduce

  1. Set "voice": { "enabled": true, "mode": "tap" }.
  2. Tap to start dictating. Say a sentence or two.
  3. Pause for more than 15 seconds while you think about the next part (or, alternatively, keep talking past the 2 minute mark).
  4. Recording ends on its own and the partial prompt is submitted to the model without you pressing anything.

Suggested fix

  1. Decouple the timeout from submission. Gate the auto-submit on an explicit user-initiated finish, not on mode === "tap" alone — e.g. pass the finish reason through #m() and skip submit() when the reason is silence-timeout or max-duration. This is the small change that removes the data loss.
  2. Make the timers configurable, e.g. voice.tapSilenceTimeoutMs and voice.tapMaxDurationMs, with 0/null meaning "no cap".
  3. Raise the silence default. 15s is well inside the range of a normal thinking pause when you're dictating a complex prompt.
  4. Show it coming. A countdown or a colour change on the REC indicator in the last few seconds would make the cutoff predictable instead of surprising.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.245

Platform

Anthropic API

Operating System

macOS 26.1 (25B78), Apple Silicon

View original on GitHub ↗