[High severity] 1.0.60 WSL2 regression: CLI MainThread spins at ~215% CPU while idle, TUI output frozen until restart (regression of #2208)

[neerajdixit-msft2]

Severity / Impact

• Severity: High — the TUI becomes effectively unusable; live output (assistant reasoning and streamed text) never paints until the CLI is restarted.
• Impact: High — reproduces on every fresh session, immediately after a clean machine reboot, with default usage. Workflow-blocking.
• Regression of previously-fixed #2208 ("copilot cli in wsl spinning on the cpu with an unresponsive tui", reported on 1.0.10, closed as completed 2026-04-07). The same class of bug is back in 1.0.60.

Describe the bug

On 1.0.60 under WSL2 (Ubuntu-22.04), the CLI process spins at ~215–220% CPU continuously, even while idle (between turns, with no prompt running). The render/event loop is CPU-starved, so after I submit a prompt the assistant's reasoning and streamed output do not appear on screen — the UI looks frozen. The work is actually completing in the background (events are written to events.jsonl); only restarting the CLI makes the result appear.

Affected version

GitHub Copilot CLI 1.0.60 (latest; dist-tags.latest = 1.0.60).

Environment

• WSL2, Ubuntu-22.04, x86_64
• TERM=xterm-256color, not inside tmux/screen (WSL relay PTY)
• 31 GiB RAM (not memory-constrained), load average ~2–4

CPU / thread profile (the signature)

Measured on a freshly rebooted machine, fresh process, idle (no active turn):

PID 73114  total %CPU = 215–221  (cumulative since start, i.e. continuous spin)
  MainThread   ~98%   (full core)
  V8Worker     ~30%   x4   (GC/JIT helper threads thrashing)
  tokio-rt-worker ~0%
/proc/<pid>/task/<pid>/wchan = 0   (RUNNING, not blocked on I/O — confirmed busy-spin)

On 1.0.59 (same machine, same session, launched via --prefer-version 1.0.59) the identical session is healthy: MainThread idle at ~0%, no V8Worker spinning, cumulative %CPU actually decreases over time (proving near-idle). Downgrading to 1.0.59 fully resolves it.

Steps to reproduce

1. On WSL2 (Ubuntu-22.04), run copilot on 1.0.60 (interactive TUI).
2. Submit any prompt that streams reasoning/output.
3. Observe: output does not render live; top shows the CLI MainThread pegged at ~98% (≈215% total) even when idle between turns.
4. Restart the CLI — the previously "missing" output now appears.

Expected behavior

Idle CPU near 0%. Streamed reasoning and assistant output render live in the timeline without requiring a restart.

What was ruled out (so it's clearly a CLI regression, not user config)

All of the following were tested and did not fix it on 1.0.60; the spin persisted on a cold-booted machine with a fresh process:

• /compact (timeline reduced to ~120 KB)
• Trimming MCP servers (74 → 30 child processes)
• Removing a large custom-agent data folder from ~/.copilot/agents/ (stopped a 1,139-file scan, but unrelated to the spin)
• Lowering reasoning effort high → medium
• Lowering logLevel all → info
• No background subagents/sidekicks active (GITHUB_CONTEXT_SIDEKICK_AGENT=false)
• Bundled Node runtime (not the system/nvm Node)

The only change that resolves it is version 1.0.60 → 1.0.59, which strongly implicates a render/event-loop regression introduced in 1.0.60.

Additional context

• Prior fixed issue (same symptom class): copilot cli in wsl spinning on the cpu with an unresponsive tui #2208.
• The 1.0.60 changelog adds a new max reasoning-effort tier and several render-related changes; a busy-loop in the streaming render/poll path is the most likely area.
• Happy to capture a CPU/devtools trace if useful (as was attached to copilot cli in wsl spinning on the cpu with an unresponsive tui #2208).

[yudongqiu]

Same symtomps found on Mac OS running copilot cli 1.0.60

This is causing huge CPU load on my laptop. Hope to get a fix asap.

Update: I tested that if I clear the session the CPU usage goes down