VS Code extension leaks MCP server processes — one full set per session, never reaped (up to 490 processes / 26.5 GB observed) #38537

Activity

1. dvass88

   added

   extensionIssues related to the VS Code extensionIssues related to the VS Code extension

   on Aug 14, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   performance

   on Aug 14, 2026
3. github-actions commented on Aug 14, 2026

   

   github-actionsBot

   on Aug 14, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Windows Desktop 26.810.41047] Local STDIO MCP process groups accumulate and consume ~7 GB RAM #38526
   • [Linux Desktop 0.147.0] Completed v2 subagents retain full stdio MCP runtimes #38247
   • [Linux CLI 0.147.0] Completed subagents retain bundled plugin MCP processes #37870
   • Windows Codex Desktop: opening/resuming historical subagent threads spawns duplicate MCP and node_repl process stacks #37453

   Powered by Codex Action
4. xtyooo commented on Sep 4, 2026

   

   xtyooo

   on Sep 4, 2026 – with ChatGPT Codex Connector

   More actions

   Windows Codex Desktop reproduction: per-session stdio MCP bundles still accumulate after the lifecycle fix in #19753

   I can reproduce the same process-tree shape on Windows Codex Desktop. This expands the report beyond the macOS VS Code extension case and may help distinguish an app/extension session-ownership gap from the lower-level McpConnectionManager shutdown bug fixed by #19753.

   Environment

   • Windows 10 Pro x64, version 10.0.19045
   • Codex Desktop build: 26.707.31428
   • Bundled backend: codex-cli 0.144.0-alpha.4
   • Long-lived parent: one codex.exe ... app-server process
   • MCP transport: stdio
   • Packaging caveat: this is a repacked Windows distribution. I compared the extracted .vite/build payload against its preserved original ASAR backup and the core build files were byte-identical. The bundled codex.exe is the binary reporting the version above.

   Observed failure

   Before cleanup, one app-server process owned 414 descendants:

   Process	Count
   node.exe	160
   cmd.exe	140
   python.exe	40
   uv.exe	20
   uvx.exe	20
   node_repl.exe	10
   mcp-server-fetch.exe	10
   mcp-sequential-thinking.exe	10

   • App-server tree private memory: 15,542 MB
   • App-server tree working set: 10,122 MB
   • System committed memory: 32.88 / 33.67 GB (97%)
   • The repeated sets were created between 21:39 and 23:32 local time.
   • Killing/restarting the single Codex Desktop/app-server tree removed the accumulated children.

   The exact multiples are consistent with ten complete MCP startup cycles, not ten Codex app-server processes.

   Clean-start timeline

   After a full process-tree cleanup and restart:

   2026-09-04T15:53:21.036Z  AppServer response: method=thread/start
   2026-09-04T15:53:21.xxxZ  first complete stdio MCP bundle starts
   
   2026-09-04T15:55:01.718Z  maybe_resume_started for an existing thread
   2026-09-04T15:55:02.376Z  AppServer response: method=thread/resume
   2026-09-04T15:55:02.xxxZ  second complete stdio MCP bundle starts
   

   There was no session/MCP shutdown event between thread/start and thread/resume. Both bundles remained direct descendants of the same app-server process.

   This is especially easy to trigger in Desktop because startup opens/prewarms a new-thread route, then navigating to an existing conversation resumes a second session.

   Why this appears to survive #19753

   The local backend appears to contain the #19753 lifecycle code: its binary contains the added strings MCP client is shut down, failed to initialize MCP client during shutdown, and Shutting down Codex instance.

   PR #19753 added explicit MCP teardown for session shutdown, submission-channel closure, manager refresh/replacement, and temporary connector probing. Based on the absence of a shutdown event in this reproduction, the first session appears to remain owned/alive when the UI resumes another thread, so its manager is neither replaced nor shut down. The lower-level termination code cannot run if the app-server session never reaches a shutdown path.

   This suggests a remaining lifecycle gap above RmcpClient::shutdown() rather than the original absence of an MCP process terminator.

   Mitigation experiment

   I reduced the enabled MCP configuration to four actually used servers (fetch, github, playwright, and the Desktop-managed node_repl) and restarted cleanly:

   • Initial steady state: 20 descendants, 709 MB private memory
   • After further normal session activity: three repeated bundles, 50 descendants, 1,804 MB private memory
   • Direct bundle start times: 00:14:12, 00:26:46, and 00:26:49 local time
   • Disabled MCP servers did not reappear

   This bounds the impact but confirms the per-session accumulation still occurs and scales linearly with the number of retained bundles.

   Suggested regression coverage / investigation

   An app-server integration test could use a stub stdio MCP server that writes its PID, then reproduce the Desktop ownership sequence:

   1. thread/start session A and wait for MCP A's PID.
   2. Resume session B through the same app-server client/owner flow.
   3. Exercise the same detach/navigation/owner transition used by Desktop.
   4. Assert MCP A exits after session A has no active turn and no owners/subscribers.
   5. Assert MCP B remains alive, so legitimate parallel threads are not reaped.

   The key question appears to be which layer should declare session A unreachable: the Desktop/extension client, app-server owner/subscription tracking, or a bounded idle-session eviction policy. Simply shutting down the previous session on every thread/resume would break legitimate parallel work, so cleanup likely needs to follow ownership plus active-turn state.

   I can provide additional sanitized process snapshots or run a targeted test build if maintainers identify the intended session-detach path.
5. vangj commented on Sep 20, 2026

   

   vangj

   on Sep 20, 2026

   More actions

   Linux reproduction on Codex CLI 0.154.0 with a project-local stdio Graphify MCP server:

   • 47 retained Python MCP server processes under the long-lived Codex app-server process
   • 6.51 GiB aggregate RSS
   • 5 loaded server processes at roughly 0.9-1.0 GiB RSS each
   • 66 abandoned graph-refresh staging directories consuming about 34 GiB
   • the graph artifact is 270,344,485 bytes
   • a direct fresh CLI query succeeds, taking 20.4 seconds and peaking at 956,328 KiB RSS
   • in the affected session, the project MCP registration is enabled, but the Graphify MCP tools are unavailable

   This resembles the app-server ownership gap described above rather than the lower-level shutdown defect fixed by #19753: old per-session server trees remain live, while a direct non-MCP invocation still works. The large graph amplifies the memory impact of every retained MCP process, but it does not explain why obsolete per-session processes remain owned.

   The corresponding downstream investigation was rocketvector/darkstar-bbn#940. We are closing it as an upstream lifecycle issue rather than convening a repository architecture council. No ambiguous processes were terminated during diagnosis.
6. chrisl10 commented on Oct 15, 2026

   

   chrisl10

   on Oct 15, 2026

   More actions

   Adding a data point that extends this beyond the VS Code extension: the same per-session spawn-without-reap happens under any long-lived codex app-server process driven programmatically (orchestrator creating threads over the MCP interface), codex-cli 0.162.1, macOS.

   Observed on one engine over a few hours of multi-thread work: 1 MCP child at engine start, +2 when a second thread came up, +11 spawned within 2 seconds during a thread-creation burst, total 14 live children (~65 MB RSS each, ~0.9 GB) with zero reaped, including the children from the first hour, after threads finished their work.

   Two extra signals that may help triage:

   1. The 11-at-once fork burst coincided with the orchestrator's engine health poll timing out ~45 seconds later, so the spawn storms are externally visible as engine stalls, not just a slow leak.
   2. Reproduction is simple without the extension: start codex app-server, create several threads programmatically, then pgrep -f <your-mcp-server> | wc -l climbs per thread and never decreases, even after those threads complete.

   This suggests the leak lives in the app-server/engine MCP lifecycle itself rather than the extension layer.