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

What version of the IDE extension are you using?

openai.chatgpt 26.803.41515 and 26.803.61601 (macOS x86_64 binary) — reproduced on both

What subscription do you have?

pro 20x

Which IDE are you using?

VS Code

What platform is your computer?

macOS (Darwin 25.5.0), x86_64

What issue are you seeing?

Each Codex session spawns a complete set of the configured MCP servers as children of the extension's codex app-server process. When a session ends (or a new one starts), the old set is never terminated. Sets accumulate for as long as the extension host lives — days — at roughly 80–160 MB RSS per process.

Setup: ~8 MCP servers configured (argent, @playwright/mcp, xcodebuildmcp, @upstash/context7-mcp, @lottiefiles/creator-mcp, plus 3 project-local stdio servers).

Measured occurrences (same machine, Aug 6–14, 2026)

• Aug 6: 14 leaked sets, 110 processes, ~8 GB resident; swap 8.2/9.2 GB
• Aug 9: ~20 sets, 243 processes, oldest 25+ h; swap 7.45/8.19 GB
• Aug 12 (worst): 71 sets, 490 processes, 26.5 GB resident; swap 25.4/26.6 GB — only 1.2 GB of swap left
• Aug 14 (twice): 19 sets / 169 processes, then 9 sets / 108 processes (~8 GB) after ~1 day of uptime — this time with swap healthy, so the leak shows up as general system jank well before memory pressure

Failure mode under pressure (Aug 12)

When memory is exhausted, MCP server startup fails, and the extension responds by respawning the entire set — we measured ~1.5 new sets per minute against only 9 actual session rollouts in ~/.codex/sessions in the same hour. That feedback loop is what users experience as "Codex could not start": the session journal shows the agent completing turns normally while the UI can't attach to MCP. The respawn storm stopped on its own the moment the leaked processes were killed.

What steps can reproduce the bug?

1. Configure a set of MCP servers for the extension (~8 in our case: argent, @playwright/mcp, xcodebuildmcp, @upstash/context7-mcp, @lottiefiles/creator-mcp, plus 3 project-local stdio servers).
2. Open VS Code with the extension and start a Codex session. A full set of MCP server processes is spawned as children of the extension's codex app-server process.
3. End that session and/or start a new one. A second full set is spawned; the first set is still running.
4. Repeat over normal daily use and leave the extension host running for hours/days.
5. Inspect the process tree (e.g. ps -eo pid,ppid,rss,etime,command | grep -i mcp, or pstree from the codex app-server / codex PID) and count the sets.

Observed: one full set of MCP server processes per session, none reaped. On this machine that reached 71 sets / 490 processes / 26.5 GB resident after several days of uptime (see the measurements above). Under memory pressure the extension additionally respawns sets at ~1.5/minute, far in excess of the actual session count in ~/.codex/sessions.

What is the expected behavior?

Old MCP server sets are terminated when their session ends, or at minimum reaped when a new set is spawned / on extension host shutdown.

Additional information

• Every leaked process (7 occasions, ~1,300 processes total) exited cleanly on plain SIGTERM; none required SIGKILL and none orphaned to init. So this appears to be purely missing lifecycle cleanup, not hung children.
• After an extension auto-update, the superseded version's extension host can linger with all its leaked children; nothing ever cleans those up either (observed Aug 12: old host holding 26 GB while the updated build failed to start).
• The parent process shape changes between builds (sometimes codex app-server owns the sets, sometimes the main codex process does), but the leak reproduces in both.

Start by tracing the VS Code extension's session lifecycle and the codex app-server process tree, using the reported MCP process reproduction and ~/.codex/sessions counts. Check how MCP server sets are spawned and how session end, replacement, and extension-host shutdown are handled. Done means old sets are terminated or reaped and memory-pressure respawning no longer accumulates processes.