[Windows 26.715] app-server retains repeated full stdio MCP batches, consuming 10.6 GB private memory

What version of the Codex App are you using?

• Codex Desktop package: OpenAI.Codex_26.715.9868.0_x64__2p2nqsd0c76g0
• Bundled Codex CLI: 0.145.0-alpha.30

What subscription do you have?

Not programmatically verified during this diagnostic session.

What platform is your computer?

• Microsoft Windows 11 Home, Chinese edition
• Version/build: 10.0.26200 / 26200
• Architecture: x64

What issue are you seeing?

Codex Desktop retained seven near-complete stdio MCP process batches under one long-lived codex.exe app-server --analytics-default-enabled process.

The batches were created during normal Desktop/code-mode usage. Superseded batches remained alive rather than returning to a bounded baseline. A heavyweight Python music-analysis server made the impact especially visible: each retained Python 3.12 worker used approximately 1.145 GB of private memory.

This reproduces on a newer Windows package than #32797 and #33531 and appears to be in the same lifecycle family as #18881 / #19753.

Process timeline

The app-server started at 10:18:48. Full MCP groups then appeared at:

| Batch | Local creation time |
|---:|---|
| 1 | 10:19:14–10:19:15 |
| 2 | 10:23:27 |
| 3 | 10:23:29 |
| 4 | 10:28:03 |
| 5 | 10:34:08 |
| 6 | 10:35:25 |
| 7 | 10:40:17 |

The two batches at 10:23 were created about two seconds apart.

Each batch typically contained the same launcher pattern:

• a Python stdio music-analysis launcher and a Python 3.12 worker;
• a Python Reaper MCP launcher and child;
• an uvx -> uv -> blender-mcp -> Python chain;
• an npx/cmd -> node notification MCP chain;
• repeated Node stdio MCP servers;
• a node_repl.exe process.

All selected launcher roots were direct children of the same Desktop app-server. Their descendants were recursively attributed through Win32_Process.ParentProcessId.

The older instances were still alive and responsive when inspected. This does not look like individual MCP servers crashing and being restarted; it looks like complete MCP managers/pools being created again while previous pools remain retained.

Memory and cleanup evidence

Immediately before cleanup:

• seven Python 3.12 music-analysis workers alone accounted for roughly 8 GB private memory;
• six older MCP batches contained 42 direct launcher roots and 73 total tree members;
• those older trees held approximately 9.22 GB private memory.

A controlled cleanup terminated descendants before launcher roots while explicitly protecting the app-server and unrelated workloads:

• old selected MCP processes terminated: 73;
• estimated private memory released: 9.22 GB;
• newest MCP batch remained available;
• Codex Desktop and the active thread remained running.

The heavyweight MCP entries were then disabled, and the newest matching trees were terminated:

• additional processes terminated: 13;
• additional estimated private memory released: 1.44 GB;
• matching Reaper/music-analysis/Blender/notification launcher roots afterward: 0.

Total private memory represented by the selected stale/current MCP trees was approximately 10.66 GB.

A separate long-running Python 3.10 workload was excluded by explicit PID allowlist and remained alive throughout both cleanup operations. No project application process was counted as part of the MCP totals.

Steps to reproduce

1. Configure several global stdio MCP servers, including at least one Python server with a meaningful startup/memory cost.
2. Launch Codex Desktop on Windows.
3. Open/resume threads and use normal Desktop/code-mode workflows, including switching or creating side conversations.
4. Keep the main app-server alive for 20–30 minutes.
5. Enumerate direct and transitive descendants of codex.exe app-server --analytics-default-enabled.
6. Group stdio MCP launcher roots by creation time.
7. Observe repeated near-complete MCP batches remaining alive under the same app-server.

I did not deliberately call most of the affected MCP tools during the diagnostic workflow.

What is the expected behavior?

Codex should maintain a bounded MCP process baseline.

When a session, hidden/internal thread, connector probe, refresh, or MCP manager is replaced or completes, Codex should either:

• terminate the complete stdio MCP process tree owned by it;
• reuse a bounded shared MCP pool; or
• lazily start only the MCP servers that are actually needed.

A manager refresh or new side conversation should not leave every previous full MCP stack alive.

What is the actual behavior?

One long-lived Windows app-server repeatedly created complete stdio MCP stacks. Previous stacks remained alive and accumulated until manual process-tree cleanup.

The accumulation was large enough to push the machine close to its commit limit and materially degrade system responsiveness.

Workaround

The effective workaround was:

1. recursively terminate only known MCP trees under the app-server;
2. set heavyweight global MCP definitions to enabled = false;
3. re-enable the necessary servers only in trusted project-scoped .codex/config.toml files.

This prevents the expensive servers from being started for unrelated projects, but it does not address the underlying lifecycle defect.

Related reports

• #32797 — Windows 26.707 retained repeated MCP/Node process batches
• #33531 — Windows 26.707 retained MCP suites after subagents completed
• #31499 — Windows Desktop duplicate MCP stdio process pools
• #18881 — McpConnectionManager replacement leaked MCP child processes
• #19753 — merged lifecycle cleanup intended to terminate stdio MCP servers
• #21984 — request for lazy/on-demand MCP startup

This report is an additional current-build reproduction on Windows 26.715 with mixed Python, uvx and Node stdio servers and an exact creation-time/memory/cleanup record.

Privacy and diagnostics

No usernames, credentials, environment values, notification topics, private workspace names, raw thread IDs, or absolute local MCP paths are included.

I can provide a sanitized PowerShell process-tree collector and more detailed before/after snapshots if maintainers need them.