Copilot TUI hogs CPU

[memimemimemi]

Describe the bug

When I open copilot TUI, it hogs one CPU (~6-7% on a 16 core machine).

After I run a prompt, that number multiplies to e.g. 2, 3 or 4 CPUs hogged while the TUI sits idle.

Affected version

GitHub Copilot CLI 1.0.83.

Steps to reproduce the behavior

1. start copilot TUI, observe CPU usage (sometimes i need to type a bit in the prompt box for the issue to appear)
2. run a prompt or two, observe CPU usage

Expected behavior

copilot TUI CPU usage is negligible while the program sits idle.

Additional context

Ubuntu 24.04, x86_64, GitHub Copilot CLI 1.0.83..

Logs below. I opened a session, typed in the prompt box (already 1 CPU hogged at that point), then gave a plan command. after the plan.md was written and the TUI was idle, it used 3-4 CPUs.

process-1788769402724-57168.tar.gz

[vtyrtov]

I am seeing what may be the same idle TUI regression, but in my case it eventually causes a V8 heap OOM crash.

Environment

• Copilot CLI: 1.0.83
• Server OS: CentOS Stream 9, kernel 5.14.0-642.el9.x86_64
• Architecture: x86_64
• Remote client: Ptyxis on Ubuntu 24.04
• Connection: Ptyxis → SSH → tmux 3.2a → Copilot CLI
• Copilot embedded runtime: Node.js v24.18.1
• System memory: approximately 12 GB RAM and 4 GB swap

Behavior

The crash happens while the Copilot TUI is idle. No prompt or tool is running; the session is simply left open in tmux with an active remote connection.

The process continues consuming significant CPU while idle and eventually reaches its V8 heap limit:

event: Allocation failed - JavaScript heap out of memory
trigger: OOMError

javascriptHeap.memoryLimit:     2,150,629,376 bytes
javascriptHeap.usedMemory:      2,144,408,848 bytes
old_space.used:                 2,129,116,408 bytes
old_space.available:                  198,640 bytes

process RSS:                    2,577,506,304 bytes
system available memory:        3,227,889,664 bytes
CPU consumption:                         154.881%

Almost the entire heap was retained in old_space, while the host still had approximately 3 GB of available RAM. This was therefore a V8 heap-limit failure, not a kernel/cgroup OOM kill.

The diagnostic report contained only approximately 60 libuv handles and did not show the tens of thousands of active unreferenced async handles described in #4686. This may therefore be a separate idle-time memory-retention issue, potentially related to the same TUI render/event loop responsible for the CPU usage reported here.