AI-window failsafe arming check self-matches: pgrep -f 'sleep 4200' reports armed when nothing is armed
#89
Reference in New Issue
Block a user
pgrep -f 'sleep 4200' reports armed when nothing is armed
#89
Found and reproduced during the unattended run of 2026-08-30. Searched open and closed for a duplicate: none. This is a live money defect in the operating procedure, not in shipped code.
The defect
.claude/scheduled/drb-worksession.mdSTEP 5a arms a server-side shutoff so an AI evaluation window closes even if the agent crashes, then confirms it with:Run over SSH, the literal string
sleep 4200is part of the remote shell's own command line.pgrep -fmatches against the full command line, so it matches itself and prints a PID whether or not the failsafe was ever armed.Reproduction, 2026-08-30
ssh drb 'pgrep -f "sleep 4200"'→ returned PID2867433.ssh drb 'ps -o pid,etime,cmd -p 2867433'→ no such process. It was the pgrep's own SSH shell.ssh drb 'pgrep -af "sleep 42[0]0" || echo NONE_ARMED'→NONE_ARMED.The process table was empty of failsafes the whole time. The check said otherwise.
Why this one matters
STEP 5a's own rule is "If arming fails, DO NOT open the window." That rule is the only thing standing between a crashed run and an AI window that bills every minute until a human notices. The check meant to enforce it cannot fail, so the rule has never actually been tested — every run so far has believed it was protected.
The same self-match is in the STEP 5d teardown,
pkill -f 'sleep 4200'. Therepkillwould try to kill the SSH shell issuing it, so the teardown can report having done something while a real failsafe survives and fires against a later window, closing it early and wasting the spend that window was opened to justify.Fixed in the runbook this run
Both call sites now use a self-excluding bracket pattern, plus an explicit liveness re-check and a
NONE_ARMEDsentinel:NONE_ARMED, or a PID not still alive on a second check, now counts as arming failed.Second, smaller drift fixed in the same pass
The runbook told each run to write the shutoff to
drb:/opt/drb/ai_off.py. The working tooling has actually lived at/opt/drb/aiwin/since 2026-08-26 —ai_on.py,ai_off.py,ai_state.py,ai_common.py,corr_dump.pyand.shwrappers. Following the runbook literally meant re-creating a file next to a working copy at a different path, with the wrapper still pointing at the old one. The runbook now names/opt/drb/aiwin/and says to reuse what is there.State confirmed while checking, both good
stt_enabled: false,correlation_enabled: false. No window was left open. Last window ran 2026-08-26.Why this is filed rather than just fixed
The runbook is a local file at the
Version 5Croot, which is not a git repository, so the fix has no commit and no history. This issue is the durable record. Related: #57 (standing correlation-quality evaluation procedure) owns the window procedure and should absorb this if it is ever rewritten.Refs #57, #62.
Closing - fixed and verified, unattended run 2026-08-31.
Both halves of this now use a pattern that cannot match itself:
.claude/scheduled/drb-worksession.md(sections 5a and 5d) usespgrep -af 'sleep 42[0]0', and carries an explicit warning explaining why the naive pattern self-matches over SSH and why a false positive here is the dangerous direction - it would open an AI window with no backstop at all.drb:/opt/drb/aiwin/(ai_common.py,ai_off.py,ai_on.py,ai_state.py,corr_dump.py) contains no occurrence ofpgrep -f 'sleep 4200'anywhere.No broken occurrence of the self-matching check remains in either the runbook or the server tooling.