[BUG] [Linux/WSL2] Agent-view reconnect-hang on resuming a pre-reboot background session — Ctrl+C swallowed, no in-TUI abort

TL;DR — On Linux/WSL2 with a multi-instance setup (separate CLAUDE_CONFIG_DIR/daemon per instance), resuming a background session whose worker process and unix sockets were destroyed by a host restart (wsl --shutdown) drops the agent view (claude agents) into a "Session not responding — restarting it… / reconnecting" hang, and Ctrl+C is swallowed because the input loop is blocked on the daemon round-trip. The "Ctrl+C/Esc dead while agents run" bug fixed in v2.1.186 does not cover this reconnect-loop variant; it still reproduces on v2.1.191 (latest). The only escapes are out-of-band.

Environment

• Claude Code 2.1.191 (Linux/WSL2 — Ubuntu under WSL2)
• Multi-instance setup: a separate CLAUDE_CONFIG_DIR per instance, so a separate background daemon/supervisor per instance
• Background sessions started and managed through the agent view (claude agents)

What happens

After wsl --shutdown (or any host reboot) and relaunch, pre-reboot background sessions show as failed/red in the agent view (documented: "Sessions show as failed after shutdown"). Attaching/resuming one drops into "Session not responding — restarting it…" and then hangs or loops instead of cleanly cold-restarting from the on-disk transcript.

While in that hang, Ctrl+C does nothing — no abort, no detach. The input loop is coupled to the attach/reconnect lifecycle, so when the worker round-trip blocks, no keystroke is serviced. The only way out has been killing the pane out-of-band.

Steps to reproduce

1. Start one or more background sessions and open the agent view: claude agents
2. Restart the host: wsl --shutdown (from Windows), then relaunch WSL
3. Relaunch Claude Code and open claude agents again
4. Select a pre-reboot session (shows failed/red) and attach/resume it
5. Observe: "Session not responding — restarting it… / reconnecting" that hangs or loops
6. Press Ctrl+C — observe that it is swallowed (no effect)

Expected: the documented happy path — attach/peek/reply and the session cold-restarts from where it left off; and Ctrl+C (or a documented key) aborts/detaches at any time.

Actual: the resume hangs/loops and Ctrl+C is dead; escape is only possible out-of-band.

Why (best understanding)

The reboot destroys the worker PID and its rendezvousSock/ptySock (under /run/user/<uid>, recreated fresh at boot). The supervisor can't reconnect to the dead socket, so it must cold-restart a fresh worker and replay the transcript; when that hits a transient socket error or a cwd/transcript-path mismatch it loops rather than completing. A per-instance CLAUDE_CONFIG_DIR (separate daemon per instance) raises the path-mismatch surface. Separately, the agent-view input loop is blocked on the attach round-trip, so Ctrl+C isn't serviced during the hang.

Relationship to existing issues (not a duplicate)

This is the Linux/WSL2 + multi-instance manifestation, and it combines two symptoms no single open issue captures:

• #70291, #68789, #65216 — same daemon-resume-loop family, but all macOS, and triggered by cwd-mismatch / transient socket error / worktree relocation rather than a reboot destroying the sockets.
• #59992 — the input-loop-blocked-on-attach cause, but closed and Windows.
• #68146 — the only open Linux agent-view issue, but a different symptom (a ~52s daemon respawn-storm while the view is open, not a reconnect-hang on resume).
• v2.1.186 fixed "Esc and Ctrl+C not responding while agents run"; v2.1.191 still exhibits this reconnect-loop variant.

Workaround (out-of-band)

In-TUI escape ladder (cheapest first): Ctrl+Z (documented "detach immediately" — never stops the session), then Ctrl+X on the row (stop; press again within 2s to delete a looping row), then Ctrl+L / resize the pane (un-sticks a frozen input loop). If no keystroke is serviced at all, from a different pane:

CLAUDE_CONFIG_DIR=~/.ccs/instances/<instance> claude daemon stop --any --keep-workers
pkill -f 'claude agents'

--keep-workers restarts the wedged supervisor without killing the detached workers; pkill kills only the TUI, not the workers. Prevention: a clean claude daemon stop --any --keep-workers before a planned wsl --shutdown avoids the hard-killed-worker state on resume.

Suggested direction

On resume, if the rendezvous/pty socket is gone (ENOENT/ECONNREFUSED), cold-restart a fresh worker from the on-disk transcript instead of retrying the dead socket — bounded retries, then a clean restart rather than an indefinite loop. Separately, decouple the agent-view input loop from the attach round-trip so Ctrl+C / Ctrl+Z are serviced during reconnect.

References

• Docs: https://code.claude.com/docs/en/agent-view ("Sessions show as failed after shutdown"; Ctrl+Z detach-fallback; Ctrl+X stop/delete)
• Related: #70291, #68789, #65216, #59992, #68146