[bug] Repeated microphone prompts: three recognizers share one mic and two re-arm forever — and a denial in either is completely unlogged, so mute-by-voice can die silently

[serge-ivo]

The report

"automation pops up and asks me for microphone use all the time. Does it actually run properly or is it blocked?"

Two separate things are true, and they need separating before anything is changed.

Verified: PAGS runs three microphone consumers, and two of them restart forever

#	Consumer	API	Lifecycle
1	Main recognizer (sttRef)	getUserMedia (Whisper) or Web Speech (dictation)	Per turn
2	Dictation gate (createSpeechGate)	Web Speech SpeechRecognition	Per turn, self-restarting
3	Always-on control listener (ctrlStt)	Web Speech SpeechRecognition	Whenever voice is engaged and the main mic is idle, self-restarting

Both background ones re-arm themselves on every onend:

• gate.ts:139-149 — r.onend = () => { … try { r.start(); } … }
• use-voice.ts:918 — onEnd: () => { if (ctrlWantRef.current) { try { ctrlSttRef.current?.start(); } catch {} } }

Chrome's SpeechRecognition ends itself after a short silence, so while voice is engaged this is a perpetual start → end → start cycle. Chrome activates the microphone on every start(). If the origin's mic grant is not persistent — most commonly because "Allow this time" was chosen rather than "Allow on every visit" — Chrome re-prompts on each activation. That is the shape of "asks me all the time": not one prompt per session, one per recognizer restart.

I have not verified which prompt you are seeing (Chrome's in-page bubble vs. a macOS system dialog), and that distinction changes the fix — see "What we need from the reporter" below.

Verified: if the mic IS denied, both background recognizers fail completely silently

• use-voice.ts:917 — onError: () => { /* mic denied / no-speech — onEnd re-arms if still wanted */ }. The handler is empty and its own comment names "mic denied" as an expected case.
• use-voice.ts:918 — restart failure: catch { /* SR busy */ }.
• gate.ts:137 — r.onerror = () => {}.
• gate.ts:145-149 — after 3 failed restarts: catch { /* give up quietly */ }.

No error row, no notice, no state change, nothing in /v1/errors. Two consequences:

1. Mute-by-voice can die without a trace. The control listener is the ONLY listener running while the agent is speaking or thinking — that is the entire reason Voice: mute command only active during active recording — must work at all times (during TTS, agent processing, co-pilot chat) #153 built it, and ADR 0001 M1 requires mute to be reachable in every phase. A permission denial silently removes it, and the ADR's own "known hole" paragraph anticipates the browser-support case but not this one. An ADR 0001 violation is currently unobservable in production.
2. A dead gate changes turn handling: planNoiseRejection (turn.ts:171) discards a noise-shaped transcript when !gate.isAlive || !gate.heardSpeech, so a blocked gate makes marginal turns get dropped instead of kept.

So: is it running, or blocked?

The main path is running. Production error log, by signature:

client:voice::not-allowed   count 3   first/last 2026-08-01
client:voice::audio-capture count 15  2026-08-01 03:20 → 06:07

18 mic failures, all on 2026-08-01, none since — and the main recognizer does report (onError → reportClientError, use-voice.ts:1260). So the main recognizer is not currently being denied.

But "no errors" is not evidence the other two work, because #2 and #3 cannot report. That is the honest answer to "does it actually run properly": the part that can tell us is fine; the parts that can't are unknown, and the product has no way to know either.

Verified: the automation browser never needs the microphone, and has no policy about it

grep -niE "microphone|audio|grantPermissions|permissions:" packages/browser-runner/src → no matches. The runner:

• launches real Chrome via launchPersistentContext (runner.ts:648-665) with no permissions option, so a page it opens gets Chrome's real permission UI;
• navigates only to task URLs (runner.ts:565) — job/ATS pages. It never hosts the PAGS console; takeover is viewed from the console, not by running the console inside the automation browser;
• has no audio capability anywhere in the package.

So any mic prompt originating from the automation browser is pure noise — a site asking, nothing needing it.

One profile subtlety worth knowing: seedProfileCopy (browser-profile.ts:13-49) copies Preferences (where Chrome stores site permissions) but returns early if the destination exists (:14). So a grant made in your real Chrome after the first seed never reaches the copy unless PAGS_RUNNER_REFRESH_PROFILE=1.

What to do

1. Automation browser — suppress media prompts outright (cheap, unambiguous). It never needs the mic, so this is not a workaround, it is correct policy. Add to baseOpts.args in runner.ts:625:

"--use-fake-ui-for-media-stream",     // auto-answer the prompt, never show UI
"--use-fake-device-for-media-stream", // and hand over a synthetic device, not your mic

The pair matters: the first alone auto-grants the real microphone. Together they mean no prompt and no real audio ever reaches an automated page. Safe because nothing in the runner uses media, and the console (where voice really runs) is a different browser.

2. Make a denied background recognizer observable (this is the real bug). Give ctrlStt's onError and the gate's onerror a report — at minimum for not-allowed / service-not-allowed, which are permission verdicts and not the ordinary no-speech/aborted noise those handlers exist to ignore. Keep them silent for the benign codes. Without this, ADR 0001 M1 can be violated in production and nobody learns.

3. Surface it to the user once, not per restart. If the control listener is denied while voice is engaged, say so ("Voice commands are off — microphone blocked for this site") and stop re-arming. Re-arming into a denied device forever is what turns one denial into an endless prompt loop.

4. Reduce the churn. Three recognizers for one microphone is the root cause of the prompt frequency. The gate and the control listener never run at the same time by design (shouldRunControlListener yields while the main mic records) — worth asking whether they can be one recognizer with two consumers. That is a design change, not a fix, and should not block 1-3.

What we need from the reporter to finish this

The remaining question is which prompt it is, and I cannot determine that from the repo:

• Chrome in-page bubble ("proagentstore.online wants to use your microphone") → cause is a non-persistent grant + the restart loop. Fix: choose "Allow on every visit" in the site settings; items 2-4 above make it diagnosable.
• macOS system dialog ("«App» would like to access the microphone", or an Automation prompt naming Terminal/iTerm2) → different subsystem. Note coding/terminal.ts:279-305 shells out to osascript for the tmux/iTerm2/kitty operator agents, and :283 already anticipates macOS Automation prompts. If the dialog names a terminal app rather than Chrome, that is where to look, and item 1 is irrelevant.

Which app name appears in the dialog is the one fact that decides it.

Alternatives considered and rejected

• --use-fake-ui-for-media-stream alone. Rejected: it silently auto-grants the real microphone to any automated page. Strictly worse than the prompt it removes.
• Grant the mic to the automation context via grantPermissions(['microphone']). Rejected for the same reason — it hands a live microphone to arbitrary third-party pages the agent is driving.
• Stop the control listener from restarting at all. Rejected: that is Voice: mute command only active during active recording — must work at all times (during TTS, agent processing, co-pilot chat) #153/ADR 0001 M1 deleted. Stop re-arming only on a permission denial, which is a terminal condition, not on the ordinary onend.
• Suppress the prompt in the user's own console browser. Not possible and not desirable — a real mic grant must stay a user decision.

Acceptance criteria

• The automation browser never shows a media-permission prompt, and an automated page cannot reach the real microphone.
• A not-allowed from the control listener or the gate produces a durable error row.
• A denied control listener stops re-arming and tells the user once that voice commands are unavailable.
• Benign no-speech / aborted still produce no log entries (no new flood — see [bug] The stats rollup has failed on every cron tick since it shipped — 1780 identical D1 compound-SELECT errors in 29h, and it is 97% of the error log #423).

Regression risk

• Adding reports to two handlers that fire constantly risks flooding the log; gate strictly on the permission error codes, and note reportClientError already de-dups per source+message per 30s (client.ts:46).
• Stopping the re-arm on denial must not catch a transient aborted — that would silently disable mute, i.e. cause the exact ADR 0001 failure this is meant to expose.

Related: #153 (the control listener), ADR 0001 (mute reachable in every phase — M1 and its "known hole" paragraph), #424 (the failure-logging audit; these are two more unlogged paths), #423 (why new logging must be de-duplicated).

[serge-ivo]

Shipped in b2a3634, live (CI green, Host + API workers deployed).

Items 1-3 done. Item 4 deliberately not attempted.

1. The automation browser. Both flags, in runner.ts's baseOpts.args. Your reasoning for the pair is in the code comment beside them and in a test, because --use-fake-ui-for-media-stream alone auto-grants the real microphone and "remove the redundant-looking flag" is the obvious tidy-up. The test also asserts the negative — no grantPermissions(['microphone']) anywhere — so the rejected alternative can't drift back in.

2. Denials are observable. Both handlers report: voice-control for the control listener, voice-gate for the gate. Gated on the permission codes plus audio-capture, silent for no-speech/aborted, and riding reportClientError's existing per-message 30s de-dup so a path that fires every few seconds cannot flood the log (#423).

3. Surfaced once, and the re-arm stops.

The one place I split your spec

You wrote "at minimum for not-allowed / service-not-allowed", and your regression note said the re-arm latch must not catch a transient. Those two pull in opposite directions for audio-capture, so they are now two predicates, not one:

• isReportableMicError — the two permission verdicts plus audio-capture. A missing device is diagnostic.
• isMicPermissionDenied — the two verdicts only. This is what stops the re-arm.

audio-capture can be two recognizers contending for one microphone. Latching the control listener off on that would silently disable mute-by-voice for the rest of the session — the exact ADR 0001 M1 failure this ticket exists to expose. It is reported and keeps trying. There is a test whose whole job is that negative.

What this closed on #388's side

Your framing — that an ADR 0001 violation was unobservable in production by construction — turned out to be the sharper half of this ticket. It is also the second way into the ADR's recorded "known hole", and the worse one: the API is present and the capability is gone while everything looks supported. #388's last open item (what to do about the no-Web-Speech browser) was decided in the same batch and produces the same message, because from the user's side those are one event.

Still not answered — and it needs you

Which prompt you are seeing. Everything above is worth doing either way, but the fix for the frequency depends on it:

• Chrome in-page bubble → the restart loop, and this change addresses it.
• macOS system dialog naming Terminal/iTerm2 → coding/terminal.ts's osascript Automation prompts, which none of this touches.

The app name in the dialog is the one fact that decides it.

Verified / not verified

• Verified: 6,606 unit tests, full CI bar, 249 e2e specs (chromium + webkit). The gate tests drive Chrome's real cycle (onerror then onend) and assert the restart count, so "stops re-arming" is measured rather than asserted structurally.
• Verified live: the production console bundle carries control listener refused the microphone and speech gate refused the microphone.
• Not verified: the runner flags against a real launched Chrome, and a real denied microphone in a real browser. Both need a live device.

Item 4 (three recognizers → one) is not done. You called it a design change rather than a fix and said it should not block 1-3; I agree, and it wants its own issue with the yielding rules stated, because shouldRunControlListener and the gate have different lifetimes on purpose.

[serge-ivo]

Closing — all four acceptance criteria verified against the code on main.

b2a3634 is on origin/main; CI + Deploy Host/API green on the batch head 2f33801.

#	Criterion	Verdict
1	Automation browser never prompts; an automated page cannot reach the real mic	MET (statically) — both flags in baseOpts.args, runner.ts:641-642, spread into all three launch paths (:667,:669,:675,:683); runner.test.ts:116-126 asserts both flags and the negative, not.toMatch(/grantPermissions\([^)]*(microphone|camera)/)
2	not-allowed from the control listener or the gate produces a durable row	MET — use-voice.ts:986-996 (voice-control), gate.ts:150-156 → use-voice.ts:329 (voice-gate)
3	A denied control listener stops re-arming and tells the user once	MET — use-voice.ts:990-995 clears ctrlWantRef so onEnd's re-arm at :997 is dead, plus the notice; gate latch checked in both onend (gate.ts:161) and start() (:176)
4	Benign no-speech/aborted still produce no rows	MET — both fall through both predicates; gate.test.ts "keeps re-arming through the ordinary churn a continuous recognizer produces"

Your spec-split is the right call and is verified as two predicates, not one: isMicPermissionDenied (convo.ts:911-913) = the two verdicts only, and it is what stops the re-arm; isReportableMicError (convo.ts:925-926) = those plus audio-capture, which reports and keeps trying. mute-invariant.test.ts asserts the narrowness — latching on audio-capture would silently delete mute-by-voice, the exact ADR 0001 M1 failure this ticket existed to expose.

Production console bundle carries control listener refused the microphone, speech gate refused the microphone, Voice commands are off. The runner flags are not greppable from the deployed console and were not claimed to be — packages/browser-runner is a Node package, not part of that bundle.

One correction to the closing comment

It says both handlers are gated on "the permission codes plus audio-capture". The control listener is; the gate is not — gate.ts:154 uses isMicPermissionDenied only, so a gate audio-capture still produces no row. Criterion 2 names only not-allowed, so it is met either way, but the two handlers are not symmetric as described, and a reader taking that sentence as the spec would be wrong about half of it.

Not done, correctly — and one thing that is genuinely still open

Item 4 (three recognizers → one) is not an acceptance criterion — the checklist has four items, none about consolidation, and the body itself calls it "a design change, not a fix… should not block 1-3". Legitimately its own ticket.

But the reporter's actual symptom is still undiagnosed. "Automation pops up and asks me for microphone use all the time" — the Chrome-in-page-bubble vs macOS-system-dialog question is unanswered, and no acceptance criterion covers it. Everything shipped here is worth having either way, and closing on the criteria is defensible; closing on the user's complaint is not. The one fact that decides it is still which app name appears in the dialog — if it names Terminal/iTerm2 rather than Chrome, none of this touches it and coding/terminal.ts's osascript Automation prompts are where to look. That question should carry forward rather than close with this.

Not verified, and not claimed

The runner flags against a real launched Chrome, and a real denied microphone in a real browser. Both need a live device.

[serge-ivo]

Still occurring in production — 20 recorded refusals, 10 in one 94-minute window

The owner reports voice "sometimes not capturing". list_errors shows the control listener being refused the microphone, live:

client:voice-control  "control listener refused the microphone: audio-capture"
  Aug 8 – Aug 11: 20 rows
  Aug 11 21:31:01 → 23:05:58: 10 of them

use-voice.ts:1072-1082 reports but deliberately does not latch on audio-capture, so onEnd re-arms forever (:1083). Three recognizers share one input device in Whisper mode — control listener, speech gate, MediaRecorder — which is this issue's subject.

Why it matters beyond the control channel: the timing correlates with him giving up on voice. On Chess coder 2 every user message 21:44–21:48 carries an audioKey; the messages at 22:32:14, 22:43:02 and 22:43:33 carry none (typed). That window opens 23 minutes into the refusal burst and immediately after a transcription timeout at 22:09:07. Voice returns 22:57–23:05, then the last voice message anywhere is 23:05:35 — and the last mic refusal is 23:05:58. Every user message after that is typed.

Correlation, not proof of cause, and stated as such. But two "voice-off" windows each beginning within a minute of a recorded microphone failure is the strongest live signal available, and this is a recorded failure of the mute/next/back channel regardless.

Reopening rather than filing a near-duplicate. Related new issues from the same investigation: the silent-drop paths and the gate calibration.