Feedback creatortrack reaper kills headless agent slots
The CreatorTrack dev-slot reaper (forge_creatortrack_dev_slot_reaper.py) only treats an open browser tab as evidence a slot is alive. Background Fable agents working headlessly (no browser connection) look idle and get reaped at the 45-minute mark even mid-build, deleting the worktree and DB.
Why: confirmed 4-for-4 across a batch of parallel background agents (fitness, sales-crm, social-analytics, clips) on 2026-07-06; every single one got its worktree deleted mid-session by the reaper. Each recovered by re-bootstrapping and replaying work from context (or leaving a keepalive TCP/socket connection open), but this is fragile and wastes agent time.
How to apply: when spawning a background/headless agent into a CreatorTrack dev slot, either (a) have it hold a keepalive TCP connection to its assigned port for the duration of the build, or (b) tell it to commit very frequently so a reap loses minimal work. Longer-term fix (not yet done): patch the reaper to treat slots with an active agent session or recent git commit activity as non-idle, not just browser connections. Justin has been offered this fix and said "say the word" — check before re-proposing.
[auto-memory session 1dde0e49-1ddb-40b9-89f1-05336898db9f, confidence 0.85, mode direct]
Historical (auto-merged from feedback_creatortrack_reaper_headless_agent_bug.md on 2026-07-07)¶
name: Dev-slot reaper tears down worktrees under active headless agents description: Reaper counts only browser connections as activity, killing worktrees/DBs of background Fable agents mid-session type: feedback
The CreatorTrack dev-slot reaper (reference_creatortrack_dev_slot_reaper.md) recycles idle slots after 45m based on lack of browser connections. This misfires for headless background agents (spawned via Fable/Agent tool with no browser tab open) doing long unattended builds: it deleted the worktree and DB clone mid-session for 3 of 4 parallel agents in the 2026-07-06 fitness/social/clips/sales-CRM build (fitness, sales CRM, social analytics all hit it independently). Each agent had to detect the loss, re-bootstrap the slot, and replay/recommit its work from context, wasting significant time and risking data loss if replay from context failed.
Why: reaper's activity signal (browser connection count) doesn't account for an active agent process still writing to the worktree.
How to apply: before spawning multiple long-running background Fable/Agent workers against CreatorTrack dev slots, either (a) have each agent hold a keepalive TCP connection to its assigned port (the workaround agents used ad hoc this session), or (b) fix the reaper to also check for an active Claude/agent session tied to the slot before recycling. Treat this as a known gap until the reaper is patched.
[auto-memory session 1dde0e49-1ddb-40b9-89f1-05336898db9f, confidence 0.85, mode direct]