Bug: Idle CLI sessions pin one CPU core at 100% (notify-rs debouncer loop busy-spins) #5148

Describe the bug

Environment: Copilot CLI 1.0.98, macOS 26.6.1 (Apple Silicon arm64, 14 cores).

What happened: Four concurrent CLI sessions each used about 100% of one core. Three of them stayed pegged from startup: about 52–54 minutes of CPU time over a similar wall-clock time. The sessions were started with --allow-all, or with --allow-all --autopilot --fleet. Three shared one git worktree (Maven project) as their working directory; the fourth used a sibling worktree.

Evidence that this is internal to the CLI, not agent work:

• The main Node thread is idle (parked in kevent under uv_run).
• Logs only show periodic OTel and telemetry POSTs. The log files didn't grow over a 5-second window.
• Child processes (jdtls, MCP servers, background shells) were at 0% CPU.
• sample <pid> 3 shows the thread notify-rs debouncer loop on-CPU in every sample (2478/2478) and never blocked. The notify-rs fsevents loop threads are idle.
• The hot frames are the same in two separate processes: runtime.node +0x3dd8278 (and nearby offsets), called from +0x3ddb8b4 under +0x25c8c0c, plus _platform_memcmp. It appears to be iterating or comparing over debouncer state already in memory rather than handling new filesystem events.

Expected: When no filesystem events are arriving, the debouncer thread should block (on a condvar or timeout) and use about 0% CPU.

Possible trigger (unconfirmed): Several sessions watched the same high-churn worktree (Maven target/ output, Docker/acceptance builds). A large event backlog, or a zero or expired debounce timeout, could leave the loop spinning.

Workaround: Exit and run copilot --resume <session-id>, or kill the process.

Request: Please check the debouncer loop for a busy-wait or zero-timeout path. Please also consider excluding ignored or build directories (e.g. .gitignored target/) from the watch.

Affected version

GitHub Copilot CLI 1.0.98

Steps to reproduce the behavior

Not sure but the description what happened section may provide clues

Expected behavior

No idle loop 100% cpu

Additional context

macOS 26.6.1
Herdr