Windows: multi-GiB native runtime memory bursts in desktop-hosted CLI 1.0.87-0, followed by same-process release

Start by symbolizing the captured runtime.node allocation stacks with the matching runtime.pdb, using the retained WPR/ETW traces and xperf summaries. Compare the identified ownership and lifetime with the timestamped private-memory samples from desktop-hosted sessions. Done means identifying the allocation and reclamation path and explaining or preventing the recurring multi-GiB bursts.

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:

1. Keep multiple desktop-hosted chat/coding/review sessions open.
2. Allow sessions to become idle and subsequently resume.
3. Observe large per-CLI private-memory growth and occasional large releases.
4. Restart the desktop app: a quieter period can follow, but the bursts recur.

The desktop lifecycle issue is tracked separately in https://github.com/github/app/issues/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:

• https://github.com/github/copilot-cli/issues/4694: approximately 31 GB RSS on WSL2, CLI 1.0.82, without this native stack/reclamation evidence.
• https://github.com/github/copilot-cli/issues/4251: large-session resume regression in 1.0.74 with a hundreds-of-MB event history and JavaScript OOM.
• https://github.com/github/copilot-cli/issues/4468: extension-host child-process accumulation, rather than these large allocations inside individual CLI hosts.
• https://github.com/github/copilot-cli/issues/4892: hourly extension/MCP reloads; no identity with the allocation mechanism established.

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.