[BUG] Daemon supervisor shuts down for auto-upgrade but never restarts — bg workers orphan-watchdog-killed 60s later, all in-flight sessions lost (2.1.198→2.1.199)

Environment

• Claude Code 2.1.198 → auto-upgraded to 2.1.199
• macOS 26.5.1 (25F80), Apple Silicon
• Native installer (~/.local/bin/claude → ~/.local/share/claude/versions/…)
• Daemon in transient mode ("Service install is disabled in this version — the daemon runs on demand")

What happened

With a claude agents TUI open and 4 background workers running, the binary auto-upgraded. The daemon supervisor detected the change and shut down to self-restart on the new binary — and the restart never happened. daemon.log ends at the shutdown line with no further output:

[2026-07-02T23:42:34.554Z] [supervisor] binary at /Users/apreece/.local/bin/claude changed (/Users/apreece/.local/share/claude/versions/2.1.198 → /Users/apreece/.local/share/claude/versions/2.1.199) — self-restarting for upgrade
[2026-07-02T23:42:34.555Z] [supervisor] shutting down (cause=upgrade, uptime=95103s, leases=2, live_workers=4)

~60 seconds later, all 4 workers killed themselves via their orphan watchdogs (from /tmp/cc-daemon-501/<hash>/spare/*.pty.sock.err):

2026-07-02T23:43:33.364Z orphan watchdog: ppid 30215→1, no client for 60000ms
2026-07-02T23:43:33.481Z orphan watchdog: ppid 30215→1, no client for 60000ms
2026-07-02T23:43:33.875Z orphan watchdog: ppid 30215→1, no client for 60000ms
2026-07-02T23:43:34.649Z orphan watchdog: ppid 30215→1, no client for 60000ms

All 4 in-flight background sessions were killed mid-task. The already-open claude agents TUI (2.1.198, started pre-upgrade) was left showing "Couldn't reach the background service (not running) — run 'claude daemon status'" and could no longer dispatch — it did not (or could not) restart the daemon itself.

claude daemon status afterwards:

not running

bg sessions:
  sock dir:     /tmp/cc-daemon-501/e8b5d62a
  control.sock: unreachable (connect ENOENT /tmp/cc-daemon-501/e8b5d62a/control.sock)
  bg workers:   4 in roster.json (control unreachable)
  roster.json:  updated 7636s ago
  warning:      supervisor not running but 4 workers in roster — running `claude agents` restarts the daemon and re-adopts still-running sessions; run `claude daemon stop --any` to reap them instead

(The roster pids were all dead by then — the "4 workers" were the watchdog-killed processes.)

Expected

• The supervisor's self-restart-on-upgrade should actually restart the supervisor (exec/respawn the new binary), re-adopting live workers.
• If the restart fails, it should log the failure — currently it fails completely silently; the log just ends.
• Workers should survive a supervisor upgrade-restart window longer than 60s, or the supervisor should not shut down until its replacement is confirmed up. As designed, any restart that takes >60s (or fails) guarantees loss of all in-flight background work.

Actual

Supervisor exits, never comes back, no error logged anywhere, and every background worker self-destructs 60s later. In-flight sessions lost.

Recovery (what worked)

1. claude daemon stop --any — reaps the stale roster (4 dead workers → 0)
2. Quit the stale pre-upgrade claude agents TUI (double Ctrl-C)
3. Relaunch claude agents — new 2.1.199 client spawns a fresh transient daemon; everything healthy after

Notes

• Related but distinct: #66358 — same trigger (auto-upgrade with live workers), but there the new daemon does come up and old workers fail attach with EAUTH key-skew. Here the daemon never comes up at all.
• Second daemon incident in two days on this machine; the previous one (2026-07-01) left a roster.json.corrupt.* backup, possibly related.