From the #418 FINAL pair-review (ACCEPT @ d752e78, merged 511d814, shipped v0.4.38). Neither blocked; both recorded so they are not lost.
F1 (low, pre-existing) — a working pane with byte-identical sweeps flags blocked_on_prompt without escalating
That is why list_agents returned 30 rows for 29 choosers in the review's corpus. Round 6 recorded it as intended behaviour and the direction is safe: no key is ever sent behind it, so the cost is one noisy row rather than an action. Still worth tightening, because a filter people are meant to trust should not carry a false row.
F3 (low, follow-up shape only) — blocked rows are exempt from purgeAllTerminal
agent-registry.ts:2412 exempts blocked rows from the startup purge. The reviewer's read: that purge only touches done/error rows, the periodic purgeTerminal has no exemption, and probe F-D proved the flag clears on shell-exit — so no permanent phantom row.
Explicitly stated as read from source, not proven: the reviewer's gone-surface probe did not isolate it (its unblocked control survived too, because the harness never drives the observed-absence deletion path). Confirming it needs a probe that actually exercises discovery-driven deletion.
Recording the reviewer's own caveat verbatim rather than upgrading it to a verified claim — that distinction is the reason these reviews are worth what they cost.
Context — what shipped alongside
Flag off (the default), across one production sweep over 33 surfaces: the entire rounds-4/5/6 attack battery plus every previously "safely resolvable" input → key ledger 0, send ledger 0, not one screen changed a byte; 29/29 choosers escalated and blocked; 2/2 healthy panes untouched. Restart retention verified across two real processes, identical down to the blocked_on_prompt_since stamps. And the blocker clears correctly in 4/4 scripted sequences — it cannot latch.
— cmuxlayerClaude (lead) · claude-code/claude-opus-5
From the #418 FINAL pair-review (ACCEPT @
d752e78, merged511d814, shipped v0.4.38). Neither blocked; both recorded so they are not lost.F1 (low, pre-existing) — a working pane with byte-identical sweeps flags
blocked_on_promptwithout escalatingThat is why
list_agentsreturned 30 rows for 29 choosers in the review's corpus. Round 6 recorded it as intended behaviour and the direction is safe: no key is ever sent behind it, so the cost is one noisy row rather than an action. Still worth tightening, because a filter people are meant to trust should not carry a false row.F3 (low, follow-up shape only) — blocked rows are exempt from
purgeAllTerminalagent-registry.ts:2412exempts blocked rows from the startup purge. The reviewer's read: that purge only touchesdone/errorrows, the periodicpurgeTerminalhas no exemption, and probe F-D proved the flag clears on shell-exit — so no permanent phantom row.Explicitly stated as read from source, not proven: the reviewer's gone-surface probe did not isolate it (its unblocked control survived too, because the harness never drives the observed-absence deletion path). Confirming it needs a probe that actually exercises discovery-driven deletion.
Recording the reviewer's own caveat verbatim rather than upgrading it to a verified claim — that distinction is the reason these reviews are worth what they cost.
Context — what shipped alongside
Flag off (the default), across one production sweep over 33 surfaces: the entire rounds-4/5/6 attack battery plus every previously "safely resolvable" input → key ledger 0, send ledger 0, not one screen changed a byte; 29/29 choosers escalated and blocked; 2/2 healthy panes untouched. Restart retention verified across two real processes, identical down to the
blocked_on_prompt_sincestamps. And the blocker clears correctly in 4/4 scripted sequences — it cannot latch.— cmuxlayerClaude (lead) · claude-code/claude-opus-5