[bug] Muting while a turn is transcribing deletes the words — the bubble is cleared and the in-flight transcript is then dropped or sent by an unrelated 800ms echo timer

[serge-ivo]

What the user saw

In hands-free voice: finish speaking → the pending bubble shows the words with status Transcribing… → press Mute (or say "mute") → the words vanish from the screen immediately, and depending on timing they are either never sent at all or sent silently a second later with no bubble on screen while it happens.

Expected: muting stops the mic and the agent. It should not cost the user the sentence they already finished saying. Every other path that destroys a pending utterance in this codebase hands the words back to the composer first — mute is the only one that deletes them.

Where it is

packages/sdk/src/voice/use-voice.ts:797-807 — muteFromCommand, reached by both mute channels (the voice command, and the on-screen button via toggleMute at :1644, wired at store/console/src/pages/InstanceDetail.tsx:1263):

const muteFromCommand = useCallback(() => {
  mutedRef.current = true;
  setMuted(true);
  sttRef.current?.stop();
  ttsRef.current?.cancel();          // stop the agent mid-sentence + drop the queue
  setSpeaking(false);
  speakEndedAtRef.current = Date.now();   // ← leg 2
  stopAudioMonitor();
  setMicOn(false);
  clearVoiceText();                        // ← leg 1
}, [stopAudioMonitor, clearVoiceText]);

The mechanism — two individually-correct decisions

Leg 1 — clearVoiceText() deletes a transcribing utterance whose text has not arrived yet

clearVoiceText() dispatches {type:"clear"}, and reduceDictation (machine.ts:301) returns null. At that moment the dictation is {status:"transcribing", text, heard} — the user has finished speaking and the clip is mid-upload, so the words exist but their final text does not.

The codebase already knows this exact state is worth saving. prepareConversationSwitch (machine.ts:~211-225) singles it out by name:

"A transcribing utterance is the sharpest form of it — they finished speaking and the clip is mid-upload, so the speech exists but its text does not yet. That is recovered to the composer rather than sent (the #175 contract)."

leaveForSwitch (use-voice.ts:1405-1427) does the recover then the clear. muteFromCommand does only the clear.

Blame makes this a two-commit composition, not a single mistake:

• 79f94d6 (Voice: mute command only active during active recording — must work at all times (during TTS, agent processing, co-pilot chat) #153, 2026-08-03) added speakEndedAtRef.current = Date.now() — correct: mute cancels TTS, so arm the echo tail.
• 56ca1ae ([bug] Spoken words vanish between end-of-turn and the reply — dictation should land in the thread as a pending message with a transcribing status #281, 2026-08-06) rewrote setInterim("") → clearVoiceText() — a mechanical rename during the pending-utterance work. But setInterim("") cleared a live partial string; clearVoiceText() destroys a first-class Dictation that can be in transcribing status. The same commit taught the switch path to recover a transcribing dictation and the mute path to destroy one.

Leg 2 — the surviving audio's fate is decided by an unrelated 800 ms timer

Mute deliberately stops the recorder with stop(), not stopDiscard() — that is #228's promise, so "run the tests, mute" still sends the request. So the clip uploads and lands in handleResult, where classifyResult (use-voice.ts:951-955) judges it against readGuard() — which now carries speakEndedAt = <the moment Mute was pressed>. shouldIgnoreResult (machine.ts:52) is isEchoing || paused, and ECHO_GUARD_MS is 800 (machine.ts:18).

Measured against the real modules (packages/sdk/dist/voice/machine.js, node, guard state as muteFromCommand leaves it):

bubble at mute time : {"text":"file the issue about masters games","status":"transcribing", ...}
bubble after mute   : null
switch would recover: "file the issue about masters games"

ECHO_GUARD_MS = 800
  transcript lands  200ms after Mute -> ignore
  transcript lands  700ms after Mute -> ignore
  transcript lands  799ms after Mute -> ignore
  transcript lands  800ms after Mute -> accept
  transcript lands 1200ms after Mute -> accept
  transcript lands 2000ms after Mute -> accept

So:

• < 800 ms → ignore. if (verdict === "ignore") return; (:955) is the only drop path in the voice pipeline with no reportClientError — compare :976, :1124, :531, :1416. The turn evaporates with no message, no bubble, no error row. This is exactly the shape [bug] A voice turn rejected as noise is erased along with the live capture — nothing survives, nothing is logged #377 was filed and closed for, on a path [bug] A voice turn rejected as noise is erased along with the live capture — nothing survives, nothing is logged #377 did not cover.
• ≥ 800 ms → accept → finalize → emitSend. planFinalizedTurn takes muted (turn.ts:89) but only for command matching, never to suppress the send (turn.ts:119-120). The message is sent to the agent after the user muted, with nothing on screen during the gap.

Whisper latency is ~1-2 s (the code's own estimate, :1121), so both branches are routinely reachable. The 800 ms line has nothing to do with mute: it exists to protect against a cancelled TTS tail.

Leg 3 (related, same root) — mute does not silence the next reply

maybeSpeakResponse (:766-775) has no muted check. When leg 2 sends a turn after mute, the agent's reply is spoken aloud while the UI says "Muted". ADR 0001 M2: "Mute silences both directions at once… Muting an agent that keeps talking is not mute." Today mute cancels only the speech in flight at that instant; it is not a state that suppresses speech that starts afterwards.

Why the console logs show nothing

Checked production for this account: GET /v1/admin/errors?q=voice returns 4 rows total — one noise/kept, three AudioContext suspended. Nothing corresponding to a dropped turn. That is the finding, not the absence of one: the ignore branch is the one silent drop path in the pipeline, so a lost turn leaves no trace anywhere by construction.

What to do — cheapest first

1. One line — stop arming the echo tail when nothing was speaking. Read speaking before cancel() and arm conditionally:

const wasSpeaking = !!ttsRef.current?.speaking;
ttsRef.current?.cancel();
setSpeaking(false);
if (wasSpeaking) speakEndedAtRef.current = Date.now();

The line was added in #153 to cover a cancelled TTS tail. Mute also closes the mic, so when TTS was not speaking the guard protects nothing and its only remaining effect is the 800 ms lottery above. This alone makes the outcome deterministic and preserves the control listener's raised bar during a real cancelled utterance (ADR 0001 M3 — a higher bar, not a closed door).

2. Mute must resolve the pending utterance, not delete it. Give muteFromCommand the leaveForSwitch treatment (:1412-1418) — same helpers, already tested:

const pending = prepareConversationSwitch({ mode, ttsSpeaking, dictation: dictationRef.current }).recoverText;
if (pending) {
  const noise = planNoiseRejection(pending, { gate: gateSnapshot() });
  if (noise.action === "discard") reportClientError("voice", noise.report, { transcript: pending.slice(0,200), path: "mute" });
  else onRecoveredTextRef.current?.(pending);
}
clearVoiceText();

onRecoveredText is already wired in both consumers (InstanceDetail.tsx:287, CodingTab.tsx:195). Worth extracting the recoverText derivation out of prepareConversationSwitch into a named pendingUtterance(dictation) so mute isn't calling a function named "switch".

3. Make the in-flight transcript's destination explicit, not timing-derived. With (1) applied, a post-mute transcript always reaches accept and is sent. Set a flag at mute time that handleResult consults so the arriving transcript is classified recover (→ composer) rather than accept (→ sent). Carve-out for #228: the trailing-command sites (finalize's plan.command === "mute" at :1078, and the gate's onInterim at :350) must keep sending — "run the tests, mute" is a request plus a request for quiet, and #228 exists because latching there threw the request away. Cleanest shape: a parameter — muteFromCommand({ pendingTurn: "send" }) at those two sites, "recover" everywhere else.

4. Make muted suppress TTS that starts later — maybeSpeakResponse: if (mutedRef.current) { setPaused(false); return; }.

Alternatives considered and rejected

• stopDiscard() on mute instead of stop(). Kills the upload, so nothing can be lost. Rejected: regresses Voice: mute is unreachable while the user is speaking in Whisper STT mode — works in dictation, silently not in OpenAI #228 — its fix deliberately does not latch the utterance so "run the tests, mute" still sends, and this would throw the request away, which is the exact defect Voice: mute is unreachable while the user is speaking in Whisper STT mode — works in dictation, silently not in OpenAI #228 closed.
• Keep clearing, but auto-send whatever arrives. Simplest, and it is what ≥800 ms already does. Rejected: mute is what a user reaches for when something has gone wrong (ADR 0001's own framing). Firing an agent action — with spend, and a spoken reply — off a turn they just interrupted is acting on an instruction they withdrew. The composer is visible, editable and one tap from sending; being wrong there costs one tap, being wrong the other way costs an unwanted agent run.
• Add muted to shouldIgnoreResult. One line, drops every post-mute transcript. Rejected: that is the silent-loss defect promoted to a rule, and it regresses Voice: mute is unreachable while the user is speaking in Whisper STT mode — works in dictation, silently not in OpenAI #228.
• Suppress the bubble clear entirely (leave it on screen). Rejected: it would sit in transcribing forever if the upload never lands, which is the [bug] Hands-free gives up after four failed mic restarts and says nothing — no notice, no error-log row, indistinguishable from a crash #387 "indistinguishable from a crash" shape.

Open question for the owner

After a standalone mute during transcribing, should the finished turn be sent or recovered to the composer? I would recover (reasons above, and it keeps leg 3 from mattering). The counter-argument is that the user had finished the sentence and mute was only about what happens next. Worth a decision because it is the one place fixes (3) and (4) could be simplified away.

Acceptance criteria

• Mute while a transcribing utterance is pending: the words appear in the composer (or are sent, per the decision above) — never nothing.
• The outcome is identical whether the transcript lands 200 ms or 2000 ms after the mute; no dependence on ECHO_GUARD_MS.
• "run the tests, mute" (Voice: mute is unreachable while the user is speaking in Whisper STT mode — works in dictation, silently not in OpenAI #228) still sends "run the tests" and does not also leave a copy in the composer.
• No turn is dropped without a durable log row — the verdict === "ignore" branch at :955 gets a reportClientError like every sibling drop path.
• While muted, an arriving reply is not spoken aloud.
• Mute still closes the mic and cancels in-flight + queued TTS immediately (ADR 0001 M1/M2/M4 unchanged; the control listener is untouched, so M3 is unchanged).

Regression risk

• (1) could let a real cancelled-TTS tail be transcribed — only if the mic were open at cancel time, which the conditional preserves exactly. Guard: a test asserting the tail is armed when ttsSpeaking was true at mute and not when it was false.
• (2)/(3) risk double-delivery (composer and send). Guard: the Voice: mute is unreachable while the user is speaking in Whisper STT mode — works in dictation, silently not in OpenAI #228 test above, plus one asserting a standalone mute lands the turn in exactly one place.
• (4) risk of silencing a reply the user wanted. Contained: "repeat" re-speaks it after unmute.
• Nothing here re-applies a guard to the control path or closes a mute channel, so ADR 0001 M1–M4 all hold; (1) and (4) strengthen M2. Note for whoever ships this: ADR 0001's M2 paragraph says "(Today: muteFromCommand … clears the pending capture.)" — that parenthetical is descriptive of the buggy line, not normative, and should be corrected in the same PR so the next reader doesn't take it as a requirement.

Reproduction status

Mechanism verified by reading + a measurement against the real machine.js decision functions (output above). Not reproduced end-to-end in a browser — it needs a live microphone and a mid-upload button press, which Playwright cannot drive. Recorded as such.

Related: #228 (mute must not eat the words), #281 (the pending utterance; the commit that introduced this), #377 (a rejected turn erased with nothing logged — same class, different path), #175 (the recover-to-composer contract), #153/#388/ADR 0001 (mute reachability).

[serge-ivo]

Correction: two inputs in the leg-2 analysis were asserted, not traced. Both now verified — and one changes the finding.

The probe in the issue body measured classifyResult against a guard state I built by hand from reading muteFromCommand. The pure-function output is real, but two of its inputs were my assumptions. Traced properly:

1. Does the in-flight clip actually still arrive after mute? — Yes, verified. stt.ts:114-160. At the transcribing moment _mediaRec.state is already "inactive" (the VAD's own stop() at use-voice.ts:429 fired it), so muteFromCommand's second stop() falls to the else if (this._stream) this._releaseStream() branch — it releases the mic, and does not touch the upload. Critically, stop() never sets _discard; only stopDiscard() does (stt.ts:186-190). So the transcript is delivered to handleResult. Assumption held.

2. paused/pausedAt during the transcribing window — verified, and this is the sharper point.

setPaused (use-voice.ts:236-244) stamps pausedAtRef only on the false→true edge and zeroes it on unpause. Tracing the hands-free cycle: speakAndResume ends with setPaused(false) (:760) → pausedAt = 0 → startListening(). The VAD end-of-turn path (:420-432) calls dictate({type:"endOfTurn"}) and stop() and never touches setPaused. The first setPaused(true) is inside finalize (:1094), which only runs after the transcript has arrived.

So for the entire transcribing window: paused = false, pausedAt = 0.

That is not just "my inputs were right". classifyResult (machine.ts:96-99) returns recover only when isLateTurn is true, and isLateTurn (machine.ts:84-86) requires pausedAt > 0:

return s.captureStartedAt > 0 && s.pausedAt > 0 && s.captureStartedAt < s.pausedAt;

With pausedAt = 0, recover is unreachable on this path by construction. The verdict can only ever be accept or ignore. So the composer escape hatch #175 built — the one mechanism in the pipeline designed for exactly "these words are real but the conversation moved on" — is structurally unavailable to a turn interrupted by mute. It is not that the code chooses to drop the words; it has no third option to choose.

This makes fix (3) in the issue non-optional rather than a refinement: no amount of tuning speakEndedAt reaches recover, because the recover branch is gated on a timestamp that mute never sets. Either mute sets pausedAt (it is a pause, and stamping it would make isLateTurn true for speech captured before the mute — the exact semantic pausedAt was introduced for), or the destination is carried explicitly. Setting pausedAt at mute is the smaller change and reuses the existing semantics, and is probably the right shape for fix (3) — worth preferring over the muteFromCommand({pendingTurn}) parameter I sketched, since it needs no carve-out at the #228 call sites: those reach finalize with the transcript in hand and never consult classifyResult.

Still not verified

Which branch a given mute press lands in. That depends on real transcription latency remaining at the moment you press, which I have not measured. But the traced consequence is worth stating: the remaining latency runs from ~0 to ~2s, so the 800ms threshold sits inside the window — and pressing mute promptly after you stop speaking (the natural action) puts you in the ignore branch, i.e. total silent loss. Dawdling sends. That non-determinism is the defect, and it matches the reported symptom better than either branch alone.

[serge-ivo]

Related finding: the trailing-mute strip this issue's context depends on does not actually happen

While reviewing a live transcript I found this message sent to the agent verbatim (instance bd43f4de-…, 05:04:59 UTC today):

user | "Start implementing. Mute, mute."

The user's spoken mute command was delivered to the model as part of the request.

Measured against the real compiled module

"Start implementing. Mute, mute."
   splitTrailingCommand -> text="Start implementing. Mute, mute."  command=null
   planFinalizedTurn    -> action=send  command=null

"run the tests, mute"
   splitTrailingCommand -> text="run the tests, mute"              command=null
   planFinalizedTurn    -> action=send  command=null

"run the tests, mute" is the exact example used in use-voice.ts:341-346 to describe what the code does:

"the audio already captured is still transcribed and sent, with the command word stripped by finalize (splitTrailingCommand). Latching here discarded the turn, so 'run the tests, mute' muted and threw the request away — the user's words vanished with their own command."

The comment asserts the word is stripped. It is not.

The behaviour is deliberate — the comment is what is wrong

convo.ts:846-853, the trailing branch of splitTrailingCommand, is restricted to multi-word phrases, with its reasoning stated:

"Restricted to MULTI-WORD phrases, deliberately… 'don't forget to mute' must stay a message — silently truncating it AND muting is far worse than making the user pause before saying a one-word command."

That rule is sound in isolation. The problem is that the other half of the pair does not follow it: the #228 gate path (use-voice.ts:336-351) matches control words on the gate's partial transcript, where a momentary partial of exactly "mute" matches whole-utterance and fires muteFromCommand. So a bare trailing "mute" can fire the command and remain in the message.

That is the worst of both designs:

• the user is muted (so the strip rule's premise — "we didn't treat it as a command" — is false), and
• the agent receives "Start implementing. Mute, mute." and has to guess what "Mute, mute" means.

Why it belongs here

This issue is about mute costing the user their words. This is the mirror: mute costing the user their message quality, via the same finalize path, and it undermines the #228 guarantee this issue's fix (3) is written to preserve. Whoever implements the carve-out for the trailing-command call sites will be reading use-voice.ts:341-346 as the spec — and it describes behaviour that does not exist.

Minimum action: correct the comment, so the next implementer is not designing against a false premise.

Better: make the two halves agree. Either a bare trailing "mute" is a command (fire it and strip it) or it is not (neither fire nor strip). The current split — the gate fires it, the splitter keeps it — is the only combination that is wrong from both directions.

[serge-ivo]

Shipped in 3590b69, live on proagentstore.online/console/ (CI green, Host + API workers deployed).

Implemented as filed, with the correction from your comment taken as the design — the destination is explicit, not timing-derived — and one deviation, noted below.

What landed

Leg 1 — the echo tail is armed only when TTS was actually playing. As you suggested, read speaking before cancel(). The stamp stays for a genuine cancelled utterance, so the control listener keeps the raised bar M3 permits.

Leg 2 — the destination is a stamp, not a timer. Your comment's finding was right and load-bearing: recover was structurally unreachable, because isLateTurn requires pausedAt > 0 and mute never sets it. I did not set pausedAt, though — paused also gates whether the mic may reopen (canOpenMic, and unmuteFromCommand reads it), so a mute that paused would have to unpause on unmute and would then reopen the mic in the middle of a reply still being generated. Two meanings on one flag is the drift machine.ts exists to prevent. So it is a second timestamp, mutedAt, with isMutedTurn beside isLateTurn asking the same question about the other boundary, checked FIRST in classifyResult (above the accept, or it reproduces the lottery exactly).

The pendingTurn: "send" | "recover" parameter you sketched is there too, but it is doing a smaller job than you scoped it for: it decides what happens to the BUBBLE, and it is what keeps mutedAt unstamped at the two #228 sites. It is not a carve-out bolted on afterwards — those two sites have the transcript in hand and never consult classifyResult.

Leg 2b — the words are resolved, never deleted, and land in exactly one place. planMuteTeardown (pure, in machine.ts): Whisper transcribes after stop(), so the words are still coming and the bubble stays to receive them; browser dictation has no upload, so they are handed back immediately. keepPending and recoverText are mutually exclusive by construction, asserted over every combination — recovering here AND letting the transcript land in the composer is the double-delivery your acceptance criteria forbid.

Leg 3 — maybeSpeakResponse consults muted.

The silent drop — verdict === "ignore" now reports, de-duplicated per message per 30s so an echo-heavy room can't flood the log (#423).

Your open question, answered

After a standalone mute during transcribing, should the finished turn be sent or recovered?

Recovered, for the reasons you gave. The counter-argument ("mute was only about what happens next") loses to the asymmetry: being wrong toward the composer costs one tap, being wrong toward the agent costs an unwanted run with spend and a spoken reply. Recorded as ADR 0001 M5.

#388 side

ADR 0001 gains M5, and both halves of the invariant suite cover it. The SDK half classifies candidate MUTE implementations by where the interrupted turn ends up — the same shape the M3 table uses for echo guards — so the rule outlives this implementation and still permits the other legal answer. Every fix you rejected is a row in it, including "auto-send whatever arrives", which lands in one place and still fails.

You were right about the M2 parenthetical: "clears the pending capture" was descriptive of this defect. Corrected in the same change, and the sentence now says the opposite.

Verified / not verified

• Verified: 6,606 unit tests, full CI bar, 249 e2e specs (chromium + webkit), and the shipped console bundle in production carries mutedAt / keepPending / recoverText / armEchoTail / pendingTurn and the new ignore-branch report string.
• Not verified end-to-end in a browser — it needs a live microphone and a mid-upload button press, which Playwright cannot drive. Same limitation you recorded. Worth one manual pass: hands-free, finish a sentence, press Mute while it reads "Transcribing…", and confirm the words arrive in the composer and nothing is sent.