0066 — The Supervisor is off
- Status: Superseded 2026-10-18 by ADR-0067: the Supervisor is deleted, not just off. Accepted 2026-10-18. Recorded at decision time (ADR-0004).
- Date: 2026-10-18
- Deciders: Gera. After the late-boot kill loop below was found and fixed, he decided: "I don't think we need it right now… honestly, sessions are good enough now that they don't need it… let's keep it off."
- Systems:
- the agentflow Supervisor:
supervisor/, launchdcom.propflow.agentflow-supervisoron the mini, which is rung 3 of ADR-0003's supervision ladder; - fleet-medic, the reflex rung that keeps reviving sessions;
- the mini's twin guard (
hosting-tmux.sh), which was collateral damage.
- the agentflow Supervisor:
What happened
The mini rebooted at about 00:51Z on 2026-10-18 and ran at load 130–178 afterwards.
- A freshly launched claude took about 3.5 minutes to register. One measured case: pid 973 was exec'd at 01:18:34Z and registered at 01:21:59Z. The Supervisor's readiness gate waits 75 s.
- Every respawn was therefore logged
respawn FAILED: claude never registered in the roster, anddriverSidstayed on the dead predecessor. - The next sweep took "dead, respawn" again. Its stale-kill ended the successor, which by then was registered and working its kickoff.
- 19 of 30 respawns in three hours went this way. When stopped, 12 tasks had a working Driver their task file did not name.
- The constant stream of booting sessions also made the twin guard refuse every resume-from-disk ("runs a conversation that cannot be identified"). That is why Reopen Tabs would not reopen Gera's stopped tabs.
The loop is fixed in agentflow-relay#405:
- a late boot is pending, not failed;
- a live successor in
op-<task>is adopted; - a running claude is never killed for being slow;
- a boot overdue past 15 min raises
driver-never-registered.
The decision
The Supervisor stays off until Gera turns it back on.
- Stopped: 2026-10-18 01:35:46Z, with
launchctl disable gui/501/com.propflow.agentflow-supervisorand thenlaunchctl bootout. A disable persists across reboots, soRunAtLoad/KeepAlivecannot bring it back. - ⚠️ The binary on disk is still the OLD one. The mini's
~/code/PropFlow/agentflowis onliveat #404, andsupervisor/distwas built from it. That is the build that kills slow-booting Drivers. #405 is merged tomainbut not deployed. Building is a human step in this repo (CI builds, agents don't), and movinglivewithout a build would put source ahead of the running binary, which is the inverted hazard SYSTEMS.md describes. So never bootstrap the service before building #405 (see below). - The stranded task records were corrected by hand, since #405's adopt step will not run. Of the 12 tasks that recorded a dead Driver while a live successor ran:
- 5 were re-pointed at that successor, writing
driverSidandoperatorSidequal. Backups aretask.json.bak-20261018-supervisor-off. - 4 had already been corrected by their own Drivers.
- 3 were left alone because two sessions ran under their pane: held-card-table-layout, retired-test-inbound, robot-alert-dedupe.
- 5 were re-pointed at that successor, writing
- Still running: sessions themselves. fleet-medic (local-bin, every 300 s) relaunches a leased session whose host died, unwedges a stuck host, and moves a session off a spent seat. The idle reaper (
session-cap expire), the relay and the board are unaffected.
What stops while it is off
Every phase of the sweep. The authoritative list is sweepOnce() in supervisor/src/index.ts: whatever it calls is what is not running. The list below is a far copy as of 2026-10-18, so trust the code over it. These are the ones a person will notice:
- Answered decisions keep reading "needs you". The answer bridge (
answers.ts) copies a click on a decision page into the block ledger, and that ledger is what the Decisions tab and the dock render. With the bridge off, a question shows as answered only once the session that raised it runsblocked resolveitself. - Jobs filed at /agents are not started.
POST /api/intakestill writes the request, butconsumeIntakesis what mints its Driver. - No Driver is revived or minted when one dies or a task has none. This is the part Gera judged unneeded.
- Hot, idle sessions are not auto-compacted at the context ceiling (
compact.ts). - Idle sessions holding mail are not woken, orphaned mail is not rescued (
inbox.ts), and idle Driver-first Drivers are not woken (idlewake.ts). - Red main gets no fixing owner. No single fixer claim is minted or held (
redmain.ts). - Finished tasks' loops and sessions are not closed (
releases.ts,exits.ts). - Dev servers past their idle window are not stopped (
devservers.ts). - The housekeeping alarms do not fire: frozen dock, duplicate driver records, silent watcher.
- On the Systems tab, the
supervisor loadedsignal reads down. That is true, and it is on purpose.
Turning it back on
The first six steps are on the mini, by a person, and in this order. Building before bootstrapping is what keeps the old binary from ever running.
git -C ~/code/PropFlow/agentflow log --oneline live..origin/main. Anything listed ships with the build, so read it first. On 2026-10-18 it was #405 alone.git -C ~/code/PropFlow/agentflow merge --ff-only origin/main.npm run buildin bothrelay/andsupervisor/. That isdeploy.sh's build half. Don't rundeploy.shitself yet: itskickstartfails on a disabled service.- Prove the new build is the one on disk before anything can run it.
grep -c 'adopting it, not respawning over it' supervisor/dist/index.jsmust print 1 or more, andsupervisor/dist/index.jsmust be newer than the merge of #405. A 0 means the old, killing build is still in place, so stop. launchctl enable gui/501/com.propflow.agentflow-supervisor.launchctl bootstrap gui/501 ~/Library/LaunchAgents/com.propflow.agentflow-supervisor.plist. Thenlaunchctl kickstart -k gui/501/com.propflow.agentflow-relay, so the relay runs the same commit.- Watch
~/.claude/jobs/tasks/*/supervisor.logfor two sweeps. Expectadopting it/still bootinglines, and norespawning successorfor a task whoseop-<task>holds a claude. - Then remove the "OFF" note in SYSTEMS.md and mark this ADR superseded.
Options not taken
- Leave it on, with #405. The kill loop is fixed, and the jobs above keep working. Not taken because Gera judged Driver revival unneeded now that sessions stay up on their own, and an off daemon cannot misjudge a boot.
- Turn off only revival. No switch for that exists.
SUPERVISOR_MAX_RESPAWNS=0is not one: it reads as "cap reached" and parks every task whose Driver dies. A realrevive: offswitch would be a small change if the other jobs turn out to be missed.