Agent View: home page input frozen after returning from agent detail (Windows)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/59657
2. https://github.com/anthropics/claude-code/issues/59409
3. https://github.com/anthropics/claude-code/issues/59251

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

2.1.143 installed on Windows - agents view is more unusable today than before. I second this bug, and can confirm that #59251 is still broken (maybe worse)

FleetView TUI hard-hang on second mount — regression in 2.1.141+, Windows

Probable duplicate of

• #59688 (home page input frozen after returning from agent detail, Windows, 2.1.143)
• #59720 (TUI freeze on entry + orphaned daemons, Windows 11, 2.1.143)
• #59715 (CLI freezes upon returning to agent view, v2.1.143 — CLOSED)

This report adds regression boundary, clean-user reproduction, daemon-side
forensics, and bundle-level code evidence that aren't in those threads.

Reproduction (deterministic, every time)

1. Start a Claude Code interactive CLI session.
2. Open agent view (/agents or the leftarrow shortcut → [PERF:bg-leftarrow-mounted]).
3. Navigate back to the session — works normally.
4. Open agent view a second time → TUI hard-hangs: mouse and keyboard input

are completely ignored. Only recovery is closing the terminal window or
taskkill /PID <claude.exe>.

Reproduced on a clean Windows user profile with no prior ~/.claude state.

Version matrix

| Claude Code | Behavior |
|---|---|
| 2.1.140 | Least bad — works in most flows, only occasional issues |
| 2.1.141 | Regression introduced — freeze begins occurring |
| 2.1.143 | Freeze reproduces deterministically |

This points to a change in the 2.1.141 release window as the introducing
commit. The freeze persists through 2.1.143.

Environment

• OS: Windows 11 Home 10.0.26200
• Terminal: Windows Terminal
• Shell: PowerShell 7+
• Claude Code: 2.1.143
• Build: BUILD_TIME=2026-05-15T17:39:39Z, GIT_SHA=cfb8132e4c3551e2773f41a1900efd1cc93637db

Daemon side is healthy

Investigated ~/.claude/daemon.log, daemon/roster.json, all jobs/*/state.json:

• No exception, no panic, no crash event in daemon.log during the freeze window
• Workers (999ff4a7, dac9f075, e4316f09) properly registered with pipes
• After freeze + hard kill: daemon cleanly restarts, adopts orphaned workers,

no state corruption

• Removing/quarantining a candidate ghost worker (a state:"failed" job with

no jsonl and no pipe) had no effect on the freeze — confirms bug is not
in daemon-worker reconciliation

The bug is entirely client-side (TUI/render layer).

Bundle-level code evidence

Strings extracted from bin/claude.exe (2.1.143) via grep -a on the
Bun-compiled binary:

Suspect heartbeat without observable cleanup

Sz9=1, Rz9, Jt$, li6=!1, Zt$=".fleetview-heartbeat", Iz9=5000, wF8, ni6;

• .fleetview-heartbeat with 5000ms interval (Iz9)
• No matching setInterval(...) paired with clearInterval(...) found in

the FleetView module scope (other heartbeats — session_keepalive_heartbeat
in Rr7/JM6/uX8, and bg-rv 30s heartbeat in nX8/CqA — DO have
proper paired cleanup; this one appears not to)

Module-level state (var in module scope, persistent across mount/unmount)

var Lt$, ZE, j$H, Sz9=1, Rz9, Jt$, li6=!1, Zt$, Iz9, wF8, ni6;

• Jt$ (jobs array), li6 (one-time-sort flag), wF8, ni6 — not reset

on remount. li6 is explicitly a "sort already happened" sentinel:
if(!li6) Jt$.sort(...), li6=!0; → second mount skips the sort entirely
and uses stale Jt$

Mount flow

s.stdout)?.unmount(),
await new Promise((M)=>setImmediate(M)),
Ujq(),
process.env.CLAUDE_AGENTS_SELECT=H;
let[{createRoot:_},{mountFleetView:A,seedLastJobs:f}]=await(q??inq()),
z=await _({exitOnCtrlC:!1});
clearInterval(K);
...
N("[PERF:bg-leftarrow-mounted]"),
await A(z),
await CK(0,"other",{suppressResumeHint:!0}),
process.exit(0)

The clearInterval(K) here is the loader-progress interval (cleanly
paired), not the heartbeat. The heartbeat appears to have no equivalent
in this codepath.

Hypothesis (best fit for observed symptoms)

A frozen-input/no-error/hard-kill symptom indicates a blocked event loop,
not a thrown exception. Two candidates fit:

1. Heartbeat-interval leak: .fleetview-heartbeat setInterval registered

in module-scope state on first mount, second mount adds another tick source
without clearing the first → callbacks pile up, renderer falls behind,
input events queue indefinitely.

1. File watcher leak: if .fleetview-heartbeat is a file watched via

fs.watch / chokidar, Windows ReadDirectoryChangesW handles leak if
.close() isn't called on unmount → eventual handle exhaustion or
ERROR_PIPE_BUSY on the peer named-pipes (\\.\pipe\cc-daemon-...).

A "Cannot destructure property 'mountFleetView' from null or undefined value"
string is present 3× in the binary but does not fit the symptom (it would
throw visibly, not freeze silently) — likely unrelated.

Suggested experiment for the assignee

Discriminator that needs no instrumentation: does the freeze occur on visit-2
if visit-1 was very brief (open + immediately close)?

• Yes → leak accumulates per-mount regardless of duration ⇒ **registration

leak** (heartbeat or watcher attached but never detached)

• No → leak grows with time spent in FleetView ⇒ tick accumulation

(heartbeat fires repeatedly while mounted, leaving residual work queued)

This single test discriminates between the two hypotheses above and tells
you which leak primitive to inspect.

Workaround for affected users

Avoid opening agent view a second time within the same CLI session.
If you need to check agents again, exit the CLI (/exit) and start a fresh
claude invocation. Daemon-side state and worker resume both survive this.

Diagnostic data (available on request)

Baseline snapshot from this reproduction is stored locally at:
%LOCALAPPDATA%\Temp\claude_fleetview_diag\ — contains pre-freeze
daemon/roster.json, all jobs/*/state.json, process metrics (handles,
threads, memory), and session manifest. Can attach to follow-ups if useful.

Hello! This should have been fixed in 2.1.145 - could you please update and try again?

Hello! This should have been fixed in 2.1.145 - could you please update and try again?

Still down in 2.1.146

This was fixed for me in 2.1.147, running Windows 11 PowerShell 7.6.1

2.1.148 still freezes for me. Repro: fresh start claude agents, press down to select first agent, enter, see how the session gets loaded, press left, observe UI freezes. When I do it from the second terminal window again, now that the session is loaded, it does not freeze. But it freezes when I open a second session and it gets loaded - pressing back freezes the UI.

It seems like the keyboard is frozen, because when I move with mouse over the sessions, I see the mouse reacts and I am even able to click a session and get into it, and even type in it. But when returning back, it freezes again.

Fixed in v2.1.144 — input is now correctly restored after returning from a session on Windows. Please reopen if you still see this on a current version.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.