Frequent JavaScript heap out of memory

[jbulow]

Describe the bug

Every few minutes the copilot CLI crashes with the following output:

[2525992:0x4f1e6000]  2035407 ms: Mark-Compact 3919.7 (4098.2) -> 3918.2 (4097.4) MB, pooled: 3 MB, 227.10 / 0.00 ms  (average mu = 0.100, current mu = 0.008) allocation failure; scavenge might not succeed
[2525992:0x4f1e6000]  2035520 ms: Mark-Compact 3925.0 (4097.4) -> 3918.2 (4097.4) MB, pooled: 3 MB, 100.87 / 0.00 ms  (average mu = 0.102, current mu = 0.105) allocation failure; scavenge might not succeed

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Writing Node.js report to file: report.20260904.172737.2525992.0.001.json
Node.js report completed
----- Native stack trace -----

 1: 0x757658 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [copilot]
 2: 0xc60e30  [copilot]
 3: 0xc60f1f  [copilot]
 4: 0xf047f5  [copilot]
 5: 0xf04822  [copilot]
 6: 0xf04b1a  [copilot]
 7: 0xf1581a  [copilot]
 8: 0xf19bc0  [copilot]
 9: 0x19b78a1  [copilot]
[1]    2525992 IOT instruction (core dumped)  copilot

Affected version

GitHub Copilot CLI 1.0.83-5

Steps to reproduce the behavior

1. Initiate some work
2. Wait a few minutes

Expected behavior

don't crash.

Additional context

The CLI is executed on x86_64 Ubuntu/Linux 24.04, fully updated
It is access like Windows Terminal-->ssh-->Linux-->tmux/zsh-->CopilotCLI (no difference when running directly on the linux machine)

Have tried to use NODE_OPTIONS but it is silently ignored.

[examon]

[examon's robot driving] On the NODE_OPTIONS half: this build takes Node options from a --node-options flag rather than from the environment variable, which is why yours had no effect.

copilot --node-options="--max-old-space-size=6000"

Measured on 1.0.83-5, x86_64 Linux: without the flag the heap ceiling reads 4099 MB, which lines up with the 4097.4 MB in your trace, and with it, 6003 MB. Leave headroom on the box, since old space is one part of what the process uses. I have not shown that a higher ceiling makes a real session last longer, so it is a bigger ceiling rather than a fix.

I do not have a cause for the crash itself. One thing worth checking is whether yours carries the signature in #4686, which reports about 32,000 async handles that were active and unreferenced. Reports I generated from this build put that under a libuv array, so your report.20260904.172737.2525992.0.001.json should have one too, and this prints the total entry count followed by the count matching that shape:

python3 -c "import json,sys;d=json.load(open(sys.argv[1]))['libuv'];print(len(d),sum(1 for h in d if h.get('type')=='async' and h.get('is_active') and not h.get('is_referenced')))" report.20260904.172737.2525992.0.001.json

Could you post those two numbers? A high second number would put yours next to #4686, a low one says it is something else, and neither settles the cause on its own. Reports from this build also record the working directory, host name and network interfaces, so it is worth a look before pasting anything else out of that file.