claude-code - 💡(How to fix) Fix [BUG] Windows: host CPU pressure starves Claude Code input loop — `claude agents` arrow keys/typing dead until load drops

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

On Windows, whenever host CPU is under sustained load from other processes (compiles, indexers, background jobs — not Claude itself), the Claude Code TUI loses input responsiveness. The most visible failure is in the claude agents view: arrow keys stop navigating, and sometimes typing in the prompt input stops registering entirely. Responsiveness returns once host CPU pressure drops.

Crucially, other Windows applications in the same session remain fully responsive during these periods — keyboard input continues to work normally everywhere except Claude Code. This rules out OS-wide input lag or terminal-emulator starvation. The starvation is specific to Claude Code's process.

This is the starved input loop class of bug (load-correlated, recovers when load drops), distinct from the dead input loop class (e.g. #59750) where the TUI is permanently wedged regardless of CPU state.

The most plausible root cause — consistent with the reporter's own diagnosis in #62999 — is that Claude Code's main thread does rendering, stream parsing, status updates, and stdin draining all on a single event loop. Under host CPU contention, the loop ticks slowly, and stdin reads back up behind whatever synchronous work is in flight. Native Windows apps don't have this problem because keyboard input is posted to a dedicated message queue at elevated priority; a Node/Bun TUI has no equivalent split.

What Should Happen?

Keystrokes should be drained and echoed in a way that is not gated on render or stream-processing work. The TUI should remain typeable even when the host is under CPU pressure from unrelated processes. Suggested directions:

• Drain stdin on a worker thread (or at minimum at higher priority than the render path), so keystrokes are never blocked by a React/Ink reconciliation pass.
• Coalesce/debounce re-renders in views with frequent status ticks (the claude agents view appears to re-render on every status update).
• Yield the event loop between chunks of synchronous work on the main thread.

Error Messages/Logs

(no error output; input handler appears alive but starved of cycles — keystrokes either delayed by seconds or dropped silently)

Steps to Reproduce

1. Start something CPU-heavy on the host that is not Claude Code (a large compile, a video encode, a cargo build, etc.) — enough to push overall CPU utilization high for sustained periods.
2. In a separate terminal, start claude and open the claude agents TUI.
3. Try to navigate the list with arrow keys, or type in the prompt.
4. Observe: arrow keys do not register, or register seconds late; sometimes typing in the prompt input stops entirely until host CPU pressure drops.
5. Switch to any other Windows app (browser, VS Code, Notepad) during the same period — keyboard input there remains instant and responsive.

Claude Model

Opus

Is this a regression?

I don't know — but multiple users in #12234 report the Windows freeze/lag class of bug worsened after the migration to the native Bun binary.

Last Working Version

No response

Claude Code Version

2.1.156 (Claude Code)

Platform

Anthropic API

Operating System

Windows 11 Pro 10.0.26200

Terminal/Shell

Command Prompt (cmd.exe) inside Windows Terminal

Additional Information

Cross-references — same bug class, different framings:

• #62999 — "TUI input freezes randomly mid-typing — entire prompt becomes unresponsive for minutes". Identical symptom and the right diagnosis (render loop blocked by synchronous main-thread work), but filed against Ubuntu 24.04 and tagged platform:linux. The architectural problem is cross-platform; Windows just exposes it more often because Windows lacks the priority message queue that masks the issue on macOS/Linux native apps.
• #12234 — "Claude Code freezes intermittently on Windows Terminal". Large active thread; the closest existing Windows ticket, but it's become a grab-bag covering the Bun binary regression, disabled-MCP polling, and sub-agent stdin handoff. The "external-CPU-pressure starves Claude's input loop" symptom doesn't fit any of its sub-threads cleanly.
• #59750 — "claude agents TUI fully unresponsive on Windows Terminal — broken rendering + dead input loop (2.1.143)". Same view, but a dead loop (load-independent, doesn't recover) rather than the starved loop described here.
• High-CPU root-cause threads that would plausibly fix this if resolved: #22509, #19393, #56768, #54392.
• Predecessor tickets cited in #62999, all closed inactive but describing the same underlying class: #35903, #58498, #31194, #25286.

This issue is filed to give the "host-CPU-pressure → starved input loop on Windows" symptom a clean, narrowly-scoped home, since it is currently scattered across the dead-loop, freeze, and high-CPU threads with no single ticket owning it.