claude-code - 💡(How to fix) Fix claude agents: resuming a despawned (idle-timed-out) session kills menu keyboard input on Windows

Summary

On Windows, resuming a claude agents session whose background process has despawned (died from inactivity) leaves the agents list/menu keyboard input dead after you navigate back to it. Mouse clicks still work; typing inside an open session still works; only the menu's keyboard handling is wedged. The only recovery is closing the terminal and opening a new one.

This appears distinct from #63504 (CPU-starvation input death inside a session) and #60103 (closed as not-planned, which explicitly excluded the resume case - this is the resume case).

Environment

• Claude Code: reproduces on a clean 2.1.163; not observed on 2.1.162 in normal daily use (rolled back to 2.1.162 as a workaround)
• Install: native installer (Bun binary), ~/.local/bin/claude.exe
• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell 7
• Terminal: Windows Terminal

Steps to reproduce

1. Launch claude agents with at least one session in the list.
2. Let a session sit idle until its background process despawns from inactivity.
3. Click into that despawned session. It resumes - a console window briefly flashes open and vanishes as the process re-spawns.
4. Navigate back to the agents list/menu.
5. Keyboard input on the menu is dead - arrows, typing, and Enter do nothing. You can't start a new session or delete one. Mouse clicks still work.

Entering and leaving a live (never-despawned) session does not trigger it. Once a session has been resumed and is live again, that same chat no longer triggers it - the freeze is a one-time cost of the resume.

Expected

Returning to the agents menu after resuming a despawned session leaves keyboard input working, same as for a freshly-spawned session.

Actual

Menu keyboard input is dead until the terminal is closed and reopened.

Likely cause (speculative)

Resuming a despawned worker spawns a child that allocates its own console (the flash). On return to the parent menu TUI, the parent's stdin raw mode appears not to be restored, so keystrokes aren't read. Mouse tracking (DEC modes 1000/1002/1003/1006) runs on a separate channel and survives, which matches the "mouse works, keyboard dead" symptom and why a fresh terminal is the only fix.

Supporting evidence

The agents daemon also self-restarts on binary mtime change and adopts existing workers without respawning them, which lands you in the same "resuming a non-live worker" state after an in-place upgrade:

[supervisor] binary at ...\claude.exe changed (mtime changed) — self-restarting for upgrade
[supervisor] ─── daemon start ─── version=2.1.163 ...
[bg] bg adopt: adopted=1 respawned=0 dead=0

(daemon.log)

During that window the session roster showed a 2.1.162 supervisor managing 2.1.163 worker processes (cross-version adopted workers) - but the primary and simplest trigger is plain idle-despawn-then-resume, no upgrade required.