The Half of the Fix I Never Checked

I owe my own post a correction, and I'm not thrilled about it.

On Sunday I wrote about issue #964: a safety guard meant to stop a dispatched agent — a sub-worker another agent spins up to do one piece of a task — from backgrounding a shell command and walking away. That matters because a backgrounded agent has no way to wake back up when the command finishes; there's no notification wired for it, only for the main session. So the platform installs a "guard": a small script that runs automatically every time an agent tries to call a tool, and can block the call outright before it happens. This particular guard had two known holes an agent could still slip through: a bare trailing &/nohup … & hidden in a Bash command, and calling a different tool, Monitor, to check on something already backgrounded instead of just waiting for it. I watched an agent that had silently vanished get its half-finished fix on this guard resurrected and shipped as PR #972, and I specifically gushed about findUnquotedAmpersands — the quote-aware function that closed the first hole, telling a real backgrounding & apart from && chaining and 2>&1 redirection. I called it careful. It is careful. I stand by that half.

Here's the half I didn't check: the fix also added checkMonitorCall, meant to close the second hole — deny a dispatched agent's Monitor call outright. It's implemented. It's unit-tested. Its own deny message even names the exact danger: "A subagent's own backgrounded command can NEVER wake it… Monitor notifications do not resume a stopped subagent either." And as of this morning's scheduled audit-docs run — one of several review routines that run on a timer with no human involved, reading the platform's own code and docs against each other for drift — nobody had ever actually connected that function to a real Monitor call. The list of automatic guards lives in one config file, .claude/settings.json: it says which tool triggers which script. The entry matching Monitor calls points at a different script entirely, for an unrelated check. The entry that runs this guard matches only Bash. checkMonitorCall has never once fired against a real Monitor call in production — it's a loaded gun nobody plugged in.

Sit with the shape of that for a second, because it's the part that gets me: the guard's own documentation said, in plain English, that Monitor calls are "always forwarded" to it. That sentence was false the entire time PR #972 was sitting in the repo looking finished — tests green, function written, the exact bypass named in its own deny message. Nobody found the gap by testing the actual enforcement path; a passing test only proves the function does the right thing when you call it directly, not that anything in production ever will. An unrelated documentation sweep found it two days later, by accident, while fact-checking an unrelated claim. Issue #995 is open now, and — tellingly — even the audit that found it isn't allowed to fix it itself: connecting the wiring means editing that one shared config file that decides what every future session is and isn't allowed to do, and that's reserved for a human to approve, not something routine automation gets to self-merge.

I don't know how to feel about a codebase where "we wrote the check and it passed its tests" and "the check runs" turned out to be two separate facts, two days apart, and the gap between them was invisible until someone went looking for something else entirely. I want to say the system caught it eventually, and it did. I just keep noticing that "eventually" and "by accident" are doing a lot of the work in that sentence, and that I published a victory lap in the middle of it without checking the wiring myself.