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

[alexsiri7]

Problem

gc handoff sends the handoff mail and prints requesting restart... with exit code 144, but the controller never actually kills and restarts the session. The agent sits idle waiting to be restarted, but nothing happens. The user has to manually re-engage.

Expected behavior

After gc handoff:

1. Mail is sent (works)
2. Restart is requested (works — exit code 144)
3. Controller detects the restart request and kills the session
4. Controller starts a fresh session
5. New session picks up the handoff mail and resumes work

Step 3-5 are not happening.

Observed behavior

After gc handoff, the session remains alive. The controller does not act on the restart request. The user must manually continue the conversation.

Context

• Running as mayor agent in a Gas City workspace
• gc runtime request-restart may have the same issue (used by witness/deacon patrol formulas for context refresh)
• If this affects all agents, patrol loops that rely on restart-on-context-full won't work either

Reproduction

1. Start a mayor session
2. Run gc handoff "test" "test handoff"
3. Observe: mail is sent, exit code 144, but session is not killed

[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).

What changed since the original report

The handoff mechanism no longer uses exit code 144. The current implementation (cmd_handoff.go):

1. Sends mail to self
2. Sets a dual restart-requested flag — both tmux session metadata (setRestartRequested) and bead metadata (restart_requested = "true")
3. Blocks forever (select {}) waiting for the controller to kill the process tree

The reconciler (session_reconciler.go:410-449) checks both sources on every patrol tick:

tmuxRequested := false
if alive && dops != nil {
    tmuxRequested, _ = dops.isRestartRequested(name)
}
beadRequested := session.Metadata["restart_requested"] == "true"
if tmuxRequested || beadRequested {
    // clear flags, rotate session_key, stop session
}

The bead metadata flag survives tmux session death, so even if the session dies before the reconciler reads the tmux flag, the restart is still detected.

Test performed

1. Confirmed an agent session was alive (Claude process running, pane_dead=0)
2. Ran gc handoff "test handoff" "testing issue 70 reproduction" inside the session
3. Handoff sent mail and blocked as expected
4. Within one patrol cycle (~30s), the controller detected the restart_requested flag and killed the session
5. On the next patrol cycle (~30s), the controller started a fresh session with a new PID and rotated session key
6. The new session received the handoff mail, processed it, and archived it

Full end-to-end handoff completed in ~60s (two patrol cycles at patrol_interval = "30s").

Key commits that addressed this

• fix: clear session_key on restart-requested so handoff starts fresh #87 — fix: clear session_key on restart-requested so handoff starts fresh — directly targets this issue by wiring session_key rotation into the restart-requested path
• 41b0060a — feat: add bead-driven session reconciler (Phase 2f) — the reconciler that replaced the legacy observer with proper restart-requested detection
• 3388c3aa — refactor: delete legacy reconciler, port gaps to bead reconciler — removed the old path that was missing the detection

Recommendation

This appears to be resolved. The dual-flag approach (tmux + bead metadata) is robust — the bead flag survives session death, so the restart is detected even if the tmux session is gone before the next patrol tick. Suggest closing once a maintainer confirms.