reference reaper homebase socket protection 20260715T211754

Bug (fixed 2026-07-15): scripts/forge_reap_orphan_claudes.py's sweep_stale_sockets() scanned every socket in /tmp/tmux-1000/ and unlinked any that didn't answer a tmux -S <sock> ls probe within 5s. It had no homebase exclusion (unlike the main forge_tmux_socket_sweep.sh, which already protects homebase by name). The idle Opus TUI sometimes doesn't answer fast enough, so the reaper deleted the live homebase socket roughly every 15 minutes on its own cron tick. Unlinking a socket doesn't kill the underlying tmux server/Claude process, so it also orphaned a process each time (session-count crept 17->21), and made the separate sweep script think homebase was down, triggering a restart. Net effect: ~2 notify pings/hour, 24/7, since a different service (forge-tmux-anchor.service) had already failed on 2026-07-14 06:52 and the sweep became the only thing reviving homebase.

Fix applied: added PROTECTED_SOCKET_NAMES = ("homebase",) to forge_reap_orphan_claudes.py and skip those sockets in sweep_stale_sockets(). Homebase health is now owned solely by forge_tmux_socket_sweep.sh as designed. Verified via manual reaper run: 0 stale sockets removed, socket+session survived.

Why: two independent homebase-protection mechanisms existed (name-based process protection + dedicated sweep script) but a third code path (stale-socket sweep) was never given the same guard, a classic partial-guard bug. Worth remembering when adding new cleanup/reaper logic anywhere in forge: check ALL scan paths for protected-name exclusions, not just the obvious one.

How to apply: if home-base or another named-protected session/service starts flapping again, check whether a different cleanup script (not the one you already audited) is unlinking its socket or killing its process via a separate scan path.

[auto-memory session e889b9fd-c867-426f-af9a-9c04caa65c9c, confidence 0.75, mode staged]