CopilotClient.stop() leaks the CLI server's child process tree on Windows (orphaned node/copilot.exe per session)

[tic-top]

Summary

On Windows, CopilotClient.stop() does not terminate the CLI server's child process tree — only the top-level launcher process. Every create_session() / stop() cycle therefore orphans a full copilot process tree (node.exe + the copilot.exe broker/worker/webview helpers) that survives until its own idle timeout. In a long-running app that creates one client/session per unit of work (e.g. a batch/eval harness), this is a deterministic ~1 leaked process tree per session, which accumulates and eventually OOMs the host.

Environment

• github-copilot-sdk (Python) 1.0.0b7 (also visible by inspection in current client.py)
• Copilot CLI runtime 1.0.66-0
• Windows 11, Python 3.11 (miniconda)
• Transport: StdioRuntimeConnection, use_logged_in_user=True

Root cause

CopilotClient.stop() only calls terminate() / kill() on its own launcher Popen (self._process):

# client.py (stop)
if self._process and not self._is_external_server:
    self._process.terminate()
    try:
        self._process.wait(timeout=5)
    except subprocess.TimeoutExpired:
        self._process.kill()
    self._process = None

On Windows, terminating the launcher does not cascade to its descendants. The launcher (copilot.cmd → cmd.exe) spawns node.exe, which spawns the real copilot.exe server + helper processes; these are left orphaned and alive after stop().

Reproduction

import asyncio, psutil
from copilot import CopilotClient, StdioRuntimeConnection

CLI = r"C:\Users\<you>\AppData\Roaming\npm\copilot.cmd"

def n_copilot():
    return sum(p.info["name"] == "copilot.exe"
               for p in psutil.process_iter(["name"]))

async def main():
    for i in range(5):
        client = CopilotClient(
            connection=StdioRuntimeConnection(CLI, []),
            use_logged_in_user=True,
        )
        session = await client.create_session()
        await session.send("hello")
        # ...consume events until SessionIdle...
        await session.disconnect()
        await client.stop()
        print(f"iter {i}: copilot.exe alive = {n_copilot()}")

asyncio.run(main())

Observed (Windows): copilot.exe alive grows 1, 2, 3, 4, 5 — one orphaned tree per iteration, none reaped by stop().

Expected

After await client.stop() (for a client that spawned the server), the entire CLI server process tree should be terminated, leaving no orphaned node.exe / copilot.exe processes.

Workaround

Capture the launcher PID after create_session() and kill the whole tree explicitly on teardown — e.g. psutil.Process(pid).children(recursive=True) + kill all (enumerate before killing the parent), or taskkill /F /T /PID on Windows / os.killpg on POSIX.

Suggested fix

Have the SDK own the process-tree lifecycle so stop() reaps descendants:

• Windows: assign the launcher to a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, so the OS atomically kills the tree when the job/handle closes.
• POSIX: spawn with start_new_session=True and os.killpg(os.getpgid(pid), SIGKILL) on stop.
• Or a psutil-based recursive child kill inside stop().

This is likely related to the CLI-side reports of orphaned processes (e.g. github/copilot-cli#1368, #2279) but is reproducible purely through the SDK's own create_session()/stop() lifecycle.

[tic-top]

Confirmed this still reproduces on the latest release 1.0.4 (not just 1.0.0b7): client.py's stop() still does a shallow self._process.terminate() / self._cli_process.terminate() / .kill() with no Job Object (Windows), os.killpg (POSIX), or recursive child kill — so the CLI server's node.exe/copilot.exe child tree is still orphaned per session on Windows.

[github-actions]

Bug Confirmed ✅

I investigated the reported behavior and can confirm this is a genuine bug.

What I looked at

• python/copilot/client.py — the stop() method (lines 1459–1585), force_stop() (lines 1587–1640), and the subprocess spawn logic (lines 3490–3524).

What I found

Root cause confirmed. The stop() and force_stop() methods only call terminate() / kill() on the direct Popen object (self._cli_process). Python's subprocess.Popen.terminate() and .kill() on Windows call TerminateProcess() on that single PID — they do not cascade to child processes.

The CLI is launched as copilot.cmd (a Windows batch script), which runs inside cmd.exe, which spawns node.exe, which in turn spawns copilot.exe and related helper/broker processes. Terminating the top-level cmd.exe PID leaves the entire node.exe + copilot.exe subtree alive and orphaned.

The spawn call (line 3492) uses only CREATE_NO_WINDOW:

creationflags = subprocess.CREATE_NO_WINDOW if sys.platform == "win32" else 0

There is no CREATE_NEW_PROCESS_GROUP, no Windows Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, no os.killpg, and no start_new_session=True — none of the mechanisms that would enable whole-tree termination on either Windows or POSIX.

The same shallow-kill pattern also applies to force_stop().

Why the label is bug

The documented contract of stop() is to "stop the CLI server" — leaving orphaned server processes running is clearly not the intended behavior. The leak is deterministic (one full process tree per create_session() / stop() cycle) and causes OOM in long-running batch workloads, which makes this a correctness issue, not a feature gap.

Suggested fix directions (already outlined in the issue)

• Windows: spawn with a Job Object (CREATE_NEW_PROCESS_GROUP + assign to a job with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE) so the OS kills the tree on handle close, or call taskkill /F /T /PID in stop().
• POSIX: spawn with start_new_session=True and use os.killpg(os.getpgid(pid), signal.SIGKILL) in stop().
• Cross-platform fallback: enumerate children via psutil.Process(pid).children(recursive=True), kill them before killing the parent.

Generated by Bug Handler for issue #1804 · sonnet46 798.8K · ◷