`--server --stdio` never releases a session's extension-host processes; they accumulate at 4 per session until the server exits

[bghgary]

[Filed by Copilot on behalf of @bghgary]

Summary

When copilot.exe runs as a long-lived server (--server --stdio, as the Windows desktop app hosts it), each session it creates spawns four extension-host child processes, and none are terminated when the session ends. They are released only when the whole server process exits.

Over ~3 hours of repeated short-lived sessions this reached 192 extension-host processes holding ~13 GB of working set on an otherwise idle machine.

Expected vs actual

• Expected: a session's extension hosts exit when that session ends.
• Actual: they persist for the lifetime of the server process. The count only ever grows.

Evidence

Extension hosts are copilot.exe processes whose command line ends in preloads\extension_bootstrap.mjs. Their command lines are byte-identical to one another, so they carry no session identity.

Two server processes on the same machine, measured together:

Server	Sessions	Hosts
Hosting 3 long-lived interactive sessions	3	12, stable for hours
Creating repeated short-lived sessions	44 created since start	180

The first is exactly 4 per live session and never grew. The second matches 4 per session to within one session, and not one host from a completed session had exited — sessions reporting status completed leaked identically to any other.

A third control: a one-shot invocation (copilot -p "...") leaks zero. Host count before and after is identical, so the defect appears only in server mode.

Each host is ~70 MB of working set and effectively idle (~2 s of CPU accumulated over 3 hours), so this is a pure resource leak rather than runaway work.

Reproduction

1. Run the Windows desktop app, which hosts copilot.exe --server --stdio.
2. Have it create repeated short-lived sessions — scheduled workflows do this on a timer.
3. Count copilot.exe processes whose command line contains extension_bootstrap.

The count rises by 4 per session and never falls. Restarting the app is the only thing that clears them.

Impact

Host count grew at ~48/hour, reaching 192 processes and ~13 GB before intervention. Memory pressure was the visible symptom.

Workaround

Kill surplus hosts on a timer, keeping the newest N per server process — an in-flight session's hosts are always the newest, so they are never candidates. This is a hack; there is no supported way to map a host back to its session.

Environment

• Copilot CLI 1.0.79-9
• GitHub Copilot desktop app 1.1.8
• Windows 11 build 26310