Summary
On Windows, Copilot CLI 1.0.87-0 processes hosted by the Copilot desktop app repeatedly allocate multiple GiB through the native runtime.node module. Some processes subsequently release most of that private committed memory without exiting. Restarting the desktop app temporarily reduced the behavior, but the bursts recurred.
This report concerns large native allocation bursts and memory-pressure impact, not a claim that all allocated memory is permanently leaked. Allocation stacks are captured, but the retaining objects and source functions have not been identified.
Environment
- Windows x64, OS build 26200, 64 GiB RAM.
- Copilot CLI 1.0.87-0, verified from the process executable and loaded runtime paths.
- Copilot desktop app 1.1.23.
- Desktop-hosted CLI sessions, including server/stdio operation.
- Observed on September 21, 2026, across ordinary chats and coding/review sessions, not just scheduled workflows.
Allocation-trace evidence
A local WPR/ETW capture from 2026-09-21 21:47:46.599 to 21:48:25.405 UTC retained approximately 37.85 seconds of VirtualAlloc events. ETW reported zero lost events and zero lost buffers.
xperf -a virtualalloc -totals reported:
| CLI PID, identifying only this capture |
Committed during retained events |
Observed commitment outstanding at capture end |
| 102284 |
3.43 GiB |
3.02 GiB |
| 93388 |
2.96 GiB |
2.75 GiB |
| 11948 |
2.91 GiB |
2.68 GiB |
| 97488 |
1.06 GiB |
0.83 GiB |
These numbers are not total process memory or whole-process net growth. Outstanding means commitment observed in retained events and not released by their end.
The dominant first non-Windows allocation caller is:
runtime.node+0x3ff020e
-> KernelBase.dll
-> ntdll.dll / kernel virtual-memory allocation
For PID 93388, essentially all captured COMMIT event ranges originate through this callsite on one thread named copilot-runtime. PID 11948 has the same dominant callsite and thread name. Allocations continue throughout successive five-second intervals, rather than being one isolated reservation.
The offset is an allocation-path identifier, not proof that the allocator itself is defective. Private symbols were unavailable locally.
Matching runtime identity:
- Module:
prebuilds\win32-x64\runtime.node, CLI 1.0.87-0.
- SHA-256:
4d6e025dbaca975df74a27d433dc7ae9dfd4aca658326eb7ecb574be82c5518e
- CodeView PDB:
runtime.pdb
- GUID:
ce6ff830-a0ec-aca6-4c4c-44205044422e, age 1.
Same-process release confirms spiky behavior
Separately from that trace, read-only process sampling observed PID 93108:
| UTC time |
Private committed memory |
| 21:51:34 |
7.14 GiB |
| 21:51:55 |
8.93 GiB |
| 21:52:05 |
7.96 GiB |
| 21:52:15 |
4.05 GiB |
| 21:52:25 |
0.60 GiB |
| 21:52:35 |
0.60 GiB |
PID and process creation time remained identical. Both private commitment and working set fell, so this was actual in-process release, not just working-set trimming or process termination. A previous observation similarly fell from 9.40 to 0.87 GiB without exiting.
PID 93108 started after the ETL ended, so the supplied trace does not identify the allocation/reclamation mechanism for this separate live spike.
An earlier idle-chat observation also grew from 16.3 to 17.4 GiB private memory in about 38 seconds. VirtualQueryEx showed almost all growth in private read/write committed regions, not mapped files. Its saved conversation was only approximately 193 KiB and unchanged during that measurement.
Trigger context and reproduction limits
A deterministic minimal standalone-CLI reproduction is not yet available. The observed workflow is:
- Keep multiple desktop-hosted chat/coding/review sessions open.
- Allow sessions to become idle and subsequently resume.
- Observe large per-CLI private-memory growth and occasional large releases.
- Restart the desktop app: a quieter period can follow, but the bursts recur.
The desktop lifecycle issue is tracked separately in github/app#3932. During this investigation, logs again showed idle teardown followed about 308 ms later by list_session_commands, which triggered resume-from-disk and a replacement CLI. That replacement is PID 11948 in the allocation table.
This establishes lifecycle context for one measured process. It does not prove command listing directly causes every allocation or that fixing the desktop trigger resolves all native-memory bursts.
Expected behavior / investigation request
Idle/resumed sessions should avoid recurring multi-GiB memory bursts that multiply across sessions. Please symbolize the captured native stacks with the matching runtime.pdb and investigate the allocation ownership, lifetime and eventual reclamation.
Related reports reviewed, but not established as duplicates:
Debug logs are available on request. Local CLI-generated debug bundles for five affected sessions, ETW allocation traces, module-relative stacks and timestamped memory samples have been retained. No debug logs or raw traces are attached here because they may contain sensitive conversation or machine information.
Summary
On Windows, Copilot CLI 1.0.87-0 processes hosted by the Copilot desktop app repeatedly allocate multiple GiB through the native
runtime.nodemodule. Some processes subsequently release most of that private committed memory without exiting. Restarting the desktop app temporarily reduced the behavior, but the bursts recurred.This report concerns large native allocation bursts and memory-pressure impact, not a claim that all allocated memory is permanently leaked. Allocation stacks are captured, but the retaining objects and source functions have not been identified.
Environment
Allocation-trace evidence
A local WPR/ETW capture from 2026-09-21 21:47:46.599 to 21:48:25.405 UTC retained approximately 37.85 seconds of VirtualAlloc events. ETW reported zero lost events and zero lost buffers.
xperf -a virtualalloc -totalsreported:These numbers are not total process memory or whole-process net growth. Outstanding means commitment observed in retained events and not released by their end.
The dominant first non-Windows allocation caller is:
For PID 93388, essentially all captured COMMIT event ranges originate through this callsite on one thread named
copilot-runtime. PID 11948 has the same dominant callsite and thread name. Allocations continue throughout successive five-second intervals, rather than being one isolated reservation.The offset is an allocation-path identifier, not proof that the allocator itself is defective. Private symbols were unavailable locally.
Matching runtime identity:
prebuilds\win32-x64\runtime.node, CLI 1.0.87-0.4d6e025dbaca975df74a27d433dc7ae9dfd4aca658326eb7ecb574be82c5518eruntime.pdbce6ff830-a0ec-aca6-4c4c-44205044422e, age1.Same-process release confirms spiky behavior
Separately from that trace, read-only process sampling observed PID 93108:
PID and process creation time remained identical. Both private commitment and working set fell, so this was actual in-process release, not just working-set trimming or process termination. A previous observation similarly fell from 9.40 to 0.87 GiB without exiting.
PID 93108 started after the ETL ended, so the supplied trace does not identify the allocation/reclamation mechanism for this separate live spike.
An earlier idle-chat observation also grew from 16.3 to 17.4 GiB private memory in about 38 seconds. VirtualQueryEx showed almost all growth in private read/write committed regions, not mapped files. Its saved conversation was only approximately 193 KiB and unchanged during that measurement.
Trigger context and reproduction limits
A deterministic minimal standalone-CLI reproduction is not yet available. The observed workflow is:
The desktop lifecycle issue is tracked separately in github/app#3932. During this investigation, logs again showed idle teardown followed about 308 ms later by
list_session_commands, which triggered resume-from-disk and a replacement CLI. That replacement is PID 11948 in the allocation table.This establishes lifecycle context for one measured process. It does not prove command listing directly causes every allocation or that fixing the desktop trigger resolves all native-memory bursts.
Expected behavior / investigation request
Idle/resumed sessions should avoid recurring multi-GiB memory bursts that multiply across sessions. Please symbolize the captured native stacks with the matching
runtime.pdband investigate the allocation ownership, lifetime and eventual reclamation.Related reports reviewed, but not established as duplicates:
--server --stdionever releases a session's extension-host processes; they accumulate at 4 per session until the server exits #4468: extension-host child-process accumulation, rather than these large allocations inside individual CLI hosts.Debug logs are available on request. Local CLI-generated debug bundles for five affected sessions, ETW allocation traces, module-relative stacks and timestamped memory samples have been retained. No debug logs or raw traces are attached here because they may contain sensitive conversation or machine information.