[BUG] 2.1.163: agents list stops dispatching keyboard events after ← detach — paste/mouse still work, fresh instance works concurrently (Windows Terminal + cmd, intermittent)

Preflight Checklist

• [x] Searched existing issues: #59814 (same gesture, fixed 2.1.144, closed), #63206 / #59720 (same fingerprint on 2.1.153, open), #59750. None report 2.1.163, and none include the isolation experiments below.
• [x] Single bug report
• [x] Using latest version (2.1.163)

Summary

Intermittently, returning to the claude agents session list via ← (detach) leaves the list unresponsive to all keyboard input — no navigation, no typing, dead from the first keystroke after the repaint. The failure is not in the terminal or the input stream: paste inserts text, mouse clicks select and attach sessions, and the keyboard works perfectly inside any attached session. Only the list view's key handling is gone, and nothing recovers it in place.

Isolation experiments (run during a live occurrence)

| Test | Result | Rules out |
|---|---|---|
| Host CPU during occurrence | 13% | The 2.1.160 "heavy CPU load" trigger |
| Answer all sessions' pending permission prompts (waitingFor via --json) | No recovery | A live choice menu holding keyboard focus |
| Paste, then immediately type | Paste lands; typing still dead | Stuck bracketed-paste state (a real paste's end marker doesn't flush it) |
| Resize terminal window | No recovery (and resize leaves render artifacts on Windows — separate issue) | Render-side / repaint-resettable state |
| Alt-Tab away and back | No recovery | Focus-event-resettable terminal mode |
| Launch a second claude agents in a new tab | Works fully, concurrently, while the first stays dead | Daemon-global or session-side state |

Conclusion from the table: the wedged process is still receiving input (paste and SGR mouse events are processed normally) but no longer dispatches key events to the list view. This looks like a focus/subscription leak — key routing left pointing at a destroyed overlay (prompt menu, or the attach/detach transition) and never re-attached. It is permanent for that TUI instance; only relaunch recovers (one spontaneous recovery was observed early on, unexplained).

Why 2.1.163

The agents-view enter/exit transitions were reworked in this release:

Fixed terminal misalignment and a multi-second hang when exiting the agent view by pressing Esc

Fixed keyboard input becoming permanently unresponsive after a paste operation whose end marker is dropped by the terminal

This is the latest recurrence of a repeatedly fixed family: #59814 (exact ←-detach scenario, fixed in 2.1.144), the 2.1.160 heavy-load fix, and the open 2.1.153 reports #63206 / #59720 whose fingerprint (keyboard dead, paste alive, mouse alive, sessions fine) matches exactly.

Repro

1. claude agents with ~10 background sessions (mix of busy/idle/waiting). List keyboard works.
2. Attach to a session (Enter/→). Keyboard works inside.
3. Detach with ← on an empty prompt.
4. Intermittently (observed in streaks — e.g. 3 consecutive returns, then fine, then recurring later the same day), the list repaints but ignores every key.

Environment

| | |
|---|---|
| OS | Windows 11 Pro (build 26200) |
| Claude Code | 2.1.163 (native installer, ~\.local\bin\claude.exe) |
| Terminal | Windows Terminal, Command Prompt profile |

Workaround

Open a new claude agents instance in another tab — it works immediately and concurrently; the wedged instance cannot be recovered in place.