bug: closing Claude Code session doesn't terminate the tmux session

[alexsiri7]

Problem

When the user closes/exits a Claude Code session (e.g., via /exit, closing the terminal tab, or Ctrl+C), the underlying tmux session managed by the gc controller remains alive. The user gets kicked out of the interactive session, but the claude process continues running in the tmux pane, consuming tokens on every re-prime or system reminder.

This compounds with #70 (gc handoff doesn't trigger controller restart) — the user has no way to cleanly end a session:

• gc handoff sends mail but doesn't restart (bug bug: gc handoff requests restart but controller doesn't kill/restart the session #70)
• Closing the Claude Code UI doesn't kill the tmux session
• The agent keeps running, burning tokens with no user attached

Expected behavior

When the user exits Claude Code:

1. The claude process in the tmux session should terminate
2. The controller should detect the session ended
3. If work is pending, controller should restart the session (fresh context)
4. If no work, session stays stopped until new work arrives

Observed behavior

• User closes Claude Code → gets disconnected from the session
• tmux session stays alive with the claude process still running
• Agent continues responding to system reminders and cron jobs
• Tokens are consumed with no user present
• User has to manually kill the tmux session or wait for it to die

Impact

Token waste. The mayor session was re-primed multiple times after the user tried to end it, each prime injecting the full context (~thousands of tokens) with no productive work being done.

Related

• bug: gc handoff requests restart but controller doesn't kill/restart the session #70: gc handoff requests restart but controller doesn't kill/restart the session

[rileywhite]

Investigation: unable to reproduce on current main

We investigated this with the intent to fix, but could not reproduce the behavior on current main (commit 5054185).

Test performed

1. Identified a live agent session (rig--agentX, Claude process running, pane_dead=0)
2. Sent /exit to the session via tmux
3. Confirmed pane_dead=1 within 3 seconds (remain-on-exit keeps the pane as a corpse)
4. Waited one patrol cycle (~30s at patrol_interval = "30s")
5. Controller detected the zombie, tore down the dead session, and restarted it with a fresh Claude process
6. New session primed and picked up pending work normally

What appears to have fixed this

Several changes since v0.13.4 collectively address the detection and restart path:

• e2566fe1 — perf: batch tmux state queries with short-lived cache — introduced state_cache.go with pane_dead filtering, giving the reconciler reliable liveness data
• 0746501f — fix: state cache singleflight coalescing stale data after Invalidate — fixed a race where stale cache data could mask a dead session
• 41b0060a / 1894f1bb — feat: add bead-driven session reconciler (Phase 2f) — the current reconciler with three-state zombie detection (running && !alive at session_reconciler.go:314-330)
• 3388c3aa — refactor: delete legacy reconciler, port gaps to bead reconciler — removed the old reconciler that lacked this detection
• bbaae9ea — fix: singleton pool naming, pool_slot resolution, dependency zombie check — zombie detection refinements
• 141dda20 — fix: address review findings — zombie detection, pool fpExtra, dry-run order

Related PRs that hardened the session lifecycle:

• fix: clear session_key on restart-requested so handoff starts fresh #87 — fix: clear session_key on restart-requested so handoff starts fresh
• fix: clear assignee on work beads orphaned by dead sessions #273 — fix: clear assignee on work beads orphaned by dead sessions
• fix: close drained pool session beads to unblock slot recycling #209 — fix: close drained pool session beads to unblock slot recycling

Related open issue

• bug: gc handoff requests restart but controller doesn't kill/restart the session #70 (gc handoff requests restart but controller doesn't kill/restart) is still open and was referenced as a compounding factor in this issue. Worth verifying separately.

Recommendation

This appears to be resolved by the cumulative session reconciler and state cache work. Suggest closing once a maintainer confirms, and separately verifying #70.