[BUG] TUI input lags / drops keystrokes under heavy host CPU load (e.g. compilation) — other apps stay responsive (Windows, 2.1.177)

Preflight Checklist

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

What's Wrong?

When the host machine is under heavy CPU load, the Claude Code TUI input becomes laggy and drops/buffers keystrokes — the cursor stalls, characters appear in bursts, and editing the prompt (especially repositioning with arrow keys) feels sluggish. Other interactive applications on the same machine — editor, separate terminals, browser — remain fully responsive throughout. Only Claude Code degrades.

The single most common source of this load for the people using Claude Code is compilation (e.g. a cargo/rustc, clang, tsc, or webpack build pinning most cores). This is not an edge case — heavy, sustained CPU load is the normal state of a developer machine for minutes at a time, many times a day. Whenever a build is running in another terminal, typing the next prompt into Claude Code is degraded.

Because the OS keeps every other interactive app responsive under the same load, this points at Claude Code's own scheduling rather than the machine being out of headroom: the input/render path appears to compete on equal footing with compiler threads (default thread priority and/or a render-or-work loop that doesn't yield to input), so keystroke handling is starved precisely when the rest of the dev workflow needs CPU.

This is distinct from the existing open issues:

• #58276 — Claude Code itself pegs the CPU (plan-mode streaming hot-loop). Here the load is external (a build), and Claude Code is otherwise idle waiting for input.
• #62999 — render stall the author explicitly states is not load-related ("happens even with minimal containers / low CPU usage"). This report is the opposite: the lag is correlated with host CPU load.
• #25286 / #20572 — hard freezes / hangs. This is graceful-but-painful degradation, not a hang; input always eventually lands.

What Should Happen?

Interactive input (keystroke echo, cursor movement) should stay responsive regardless of competing host CPU load — the same way every other interactive app on the machine does. The input/render path should be scheduled ahead of, or yield to, background work so that a busy compile in another process never degrades typing into Claude Code.

Error Messages/Logs

(no error output; input echo lags and keystrokes arrive in bursts while host CPU is saturated)

Steps to Reproduce

1. Start a Claude Code session and let it sit idle at the prompt (no tool call or model turn in flight).
2. In a separate terminal, kick off a CPU-heavy build that saturates most/all cores for a sustained period (e.g. a clean cargo build of a large workspace, or tsc/webpack on a large project).
3. While the build runs, type a prompt into Claude Code and use the left/right arrow keys to move the cursor around within the text.
4. Observe: cursor movement stalls, character echo lags and arrives in bursts, editing feels sluggish — for as long as the build runs.
5. For contrast, type into the editor / another terminal / browser address bar under the same load — these stay responsive.
6. When the build finishes and CPU frees up, Claude Code input returns to normal immediately.

Environment

• Claude Code: 2.1.177
• OS: Windows 11 Pro (10.0.26200)
• Terminal: Windows Terminal / PowerShell
• Reproduces without tmux and without any plugins involved.