reference reaper homebase socket sweep bug 20260715T212232

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, with no exclusion for homebase. The idle Opus TUI often doesn't answer in time, so the reaper deleted its live socket roughly every hour (~:14-15), orphaning the running tmux server + Claude process (a slow process leak, session count crept 17→21) and causing forge_tmux_socket_sweep.sh to see "no socket → down" and restart it, producing ~48 notify pings/day ("restarted itself" + "is down" each cycle).

Fix: added PROTECTED_SOCKET_NAMES = ("homebase",) and a skip check in sweep_stale_sockets(), matching the name-based protection the main sweep script already had. Verified via manual reaper run: 0 stale sockets removed, socket+session survived.

Why: name-based orphan protection existed in two places (main sweep vs the reaper's stale-socket scan) and only one had the homebase guard, a classic "protection duplicated in two code paths, only one updated" bug.

How to apply: if any other long-lived named tmux session (not just homebase) starts flapping with hourly restart/down pings, check both forge_tmux_socket_sweep.sh and forge_reap_orphan_claudes.py for matching exclusion lists, don't assume one guard covers both paths. As of this fix the reaper fix was applied to the working tree but NOT yet committed/pushed to forge main, confirm it landed before relying on it long-term.

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