claude-code - 💡(How to fix) Fix [BUG] Agent view: TUI freeze on entry, mouse-tracking leak on kill, orphaned daemons on close — Windows 11, 2.1.143

Preflight Checklist

• I have searched existing issues and this hasn't been reported as a single tracking issue
• This is a single bug report covering three tightly coupled defects in one feature (agent view) — splitting them would lose the causal chain
• I am using the latest version of Claude Code

Summary

The agent view feature shipped in the 2.1.140+ release line exhibits three distinct defects on Windows that compound into a positive feedback loop. This issue documents the full chain, root cause hypothesis, and suggested fixes. Several existing reports (#58653, #48629, #34076, #59563, #59511, #42606, #50032, #38578) each capture one slice of this. None capture the full interaction, and the duplicate-marking has left no single tracking issue for terminal-mode restoration on abnormal exit.

I'll refer to the three defects as D1 / D2 / D3 throughout.

Environment

Symptom chain — three defects that compound

D1 — Agent view freezes the entire TUI on entry

This is the headline failure. Entering agent view via either left-arrow shortcut from an active session, or claude agents standalone, locks the TUI: keyboard input is ignored, the output viewport will not scroll (input composer still scrolls — confirming the input layer is alive but the renderer is wedged). Only external Stop-Process recovers.

2.1.143's changelog asserts:

Fixed: on Windows, pressing ← in claude agents while a response was streaming could leave the agents list unresponsive to all input

This fix is not effective in my environment. The freeze reproduces on left-arrow with streaming, on left-arrow while idle, and on claude agents as a fresh command. Reproduction rate at the time of filing: ~100% (5/5 attempts after a clean process slate; see D3 for what "clean" means and why it matters).

D2 — Mouse-tracking modes not released on abnormal exit

When Claude Code is killed externally while agent view is active (the only escape from D1), the disable sequences for DECSET 1000/1002/1003/1006 are never emitted. The parent shell remains in SGR mouse-tracking mode indefinitely.

Concrete artifact — captured from a real Windows Terminal session after killing Claude Code via Get-Process claude | Stop-Process -Force while agent view was open:

[I[555;17;1M[555;17;2M[555;18;3M[555;18;4M[555;19;4M[555;19;5M[555;20;6M[555;21;7M
[555;22;8M[555;23;9M[555;23;10M[555;25;12M[555;25;13M[555;26;14M[555;27;15M[555;27;16M
…continues unbounded with every cursor movement…

These are CSI < button ; col ; row M SGR mouse-event reports leaking as literal stdout because the shell is in mouse-tracking mode but Claude Code is no longer there to consume them.

Manual recovery (this should not be necessary):

[Console]::Write([char]27 + "[?1000l" + [char]27 + "[?1002l" + [char]27 + "[?1003l" + [char]27 + "[?1006l")

This is the same defect class as #58653 (open, labeled platform:macos but reproduces on Windows), #48629 (closed as duplicate), #34076 (closed as duplicate), and #59563 (open). The cluster needs a single tracking issue.

D3 — Orphan-process cascade (the multiplier)

Not strictly an agent-view bug, but it's what makes D1+D2 catastrophic on Windows over time.

Windows does not propagate SIGHUP-equivalent on terminal close. When a user hard-closes a frozen terminal (the standard escape from D1), the claude process and all its child agent processes become orphaned. They continue running indefinitely. After ~24 hours of normal heavy use I accumulated 34 orphaned claude processes consuming ~20 GB combined RSS (on a 64 GB workstation, which is why I noticed before OOM):

PS> Get-Process claude | Measure-Object
Count : 34
PS> Get-Process claude | Measure-Object WorkingSet64 -Sum
Sum   : 20,331,495,424

These zombies hold file locks on claude.exe (blocking reinstall/upgrade), compete for terminal I/O when a new session enters agent view (further degrading D1), and silently consume system resources.

The feedback loop

D1 freezes the user → forces the only-available recovery (hard-close terminal) → which triggers D2 (mouse-tracking leak in shell) and D3 (orphaned process pool) → which makes D1 worse next time. This is why the feature degrades meaningfully within a single workday of heavy use rather than failing once and being recoverable.

Reproduction (D1 → D2)

1. claude  # in any project
2. Send a prompt that streams for >5 seconds
3. While streaming, press ← to enter agent view  → TUI freezes (D1)
4. From a separate shell:  Get-Process claude | Stop-Process -Force
5. Return to original terminal pane
6. Move mouse over the pane  →  unbounded escape-sequence output (D2)

Tested on 2.1.143; symptoms persist across both Windsurf integrated terminal and standalone Windows Terminal, indicating the bug is in Claude Code's TUI layer, not the terminal emulator.

Root cause hypothesis

D2 is a missing terminal-state restoration on abnormal exit. The fix pattern is well-established in TUI applications (vim, htop, less, kitty all do this correctly):

1. Register a signal/event handler that emits \x1b[?1000l\x1b[?1002l\x1b[?1003l\x1b[?1006l\x1b[?1004l on SIGINT, SIGTERM, and on Windows CTRL_CLOSE_EVENT / CTRL_LOGOFF_EVENT / CTRL_SHUTDOWN_EVENT via SetConsoleCtrlHandler.
2. Register an atexit handler as a backstop for process-managed shutdowns.
3. On process.on('uncaughtException') and 'unhandledRejection' — emit the restore sequence before re-throwing/exiting. This is what bites on the agent-view freeze: the renderer likely throws in a way that bypasses the normal cleanup path.

D1 — the freeze likely indicates a deadlock or unbounded render loop in the agent view's session-list reconciliation when stale sessions are present. Note in my repro: the agent view contained entries flagged "stuck on a startup dialog" — D1 fires when the dashboard tries to render this stale state. Suggested:

• Add a render timeout / watchdog in the agent-view component that drops back to the session list on detected stall.
• Filter or auto-prune sessions in a "starting" or "opening" state that have not transitioned in N seconds — these may be artifacts of D3 (orphaned daemons that never reported completion). Related: #59511.

D3 — on Windows the daemon spawn path needs to register itself in a Windows job object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE so that closing the parent console actually terminates the children. This is the only reliable cross-process cleanup primitive on Windows.

Severity

Blocker for adoption by heavy parallel users on Windows. The agent view is the entry point to the new multi-session workflow shipped in the 2.1.140+ release line. Its current state on Windows is:

• Freezes on entry (D1) → only recovery is force-kill (D2) → which corrupts the shell (D2) and orphans children (D3).
• The documented workaround ("don't open agent view") makes the feature inaccessible.
• Users on lower-memory Windows machines than mine (64 GB) will likely hit OOM before they accumulate the zombie count I did.

What I can provide

• Process tree captures with PIDs/paths/RSS at the moment of accumulation
• ~/.claude/ session-state JSONL showing the "stuck on a startup dialog" entries that correlate with D1
• A clean before/after capture of the SGR sequences from D2 (full byte stream)
• A short screen recording of the full D1→D2 reproduction in real time if useful for triage — the escape-sequence cascade is much more visceral on video than in a static capture.

Related issues — recommend linking to this thread

This bug appears to be the umbrella for a cluster that has accumulated over months:

• #58653 — D2 symptom on macOS agent view (open, platform:macos — reproduces on Windows too, see this issue)
• #59563 — D2 symptom on macOS via SSH disconnect (open)
• #59511 — D1-adjacent: agent-view session-open hang (open)
• #42606 — D2 via Ctrl+G external editor on macOS (open)
• #48629 — D2 symptom on Windows (closed as duplicate, no tracking link)
• #34076 — D2 from multi-instance Claude on Windows (closed as duplicate, no tracking link)
• #50032 — D2 via Ctrl+G with mitigation analysis (closed as duplicate)
• #38578 — terminal corruption regression from prior D2 fix in 2.1.83 (closed)
• #14479 — TUI escape sequences flooding chat (closed, related ANSI escape handling)
• #18418 — escape sequences in tool output corrupting --resume (closed, stale)
• #23581 — feature request for --no-mouse flag (closed as duplicate)

Strongly recommend this issue become the single tracking thread for D1/D2/D3 and that the closed-as-duplicate issues above be linked here so reporters can subscribe to a real resolution.

Claude Code Version

2.1.143

Platform

Anthropic API (Claude Max)

Operating System

Windows

Terminal/Shell

PowerShell (Windows Terminal and Windsurf integrated terminal both reproduce)