[Windows App 26.707.9981.0] MCP suites persist after subagents complete, reaching 10.9 GB private memory

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.9981.0

What subscription do you have?

ChatGPT Prolite

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop starts a complete stdio MCP subprocess suite for each task/subagent runtime. After subagents return a completed status, their MCP process trees can remain alive under the long-running desktop codex.exe app-server for tens of minutes.

In one measured session, 10 concurrently resident MCP suites accounted for:

| Metric | Observed |
|---|---:|
| Direct MCP launcher roots | 79 |
| Total descendants in those trees | 312 |
| node.exe processes | 138 |
| cmd.exe processes | 118 |
| Private memory | ~10.9 GB |
| Working set | ~13.22 GB |
| Threads | 2,087 |

The machine became noticeably sluggish even though CPU queue, disk queue, SSD health, and DPC/interrupt measurements were normal.

This is an independent Windows reproduction of the defect class already described in #32694, #25015, #28361, and #20883. I am opening a separate report because this reproduces on the current Windows App package 26.707.9981.0 and adds:

• exact task/subagent-to-MCP-suite timestamp correlation;
• completed subagent suites remaining resident;
• a mixed global MCP configuration rather than one isolated server;
• a controlled process-tree cleanup that returned the MCP root count to zero without terminating the Codex app.

What steps can reproduce the bug?

1. Configure several global stdio MCP servers in ~/.codex/config.toml.
2. Launch the Codex Windows App and start one task.
3. Record the direct children and descendants of the desktop app-server codex.exe.
4. Spawn multiple subagents for bounded tasks that do not need most of the configured MCP tools.
5. Wait until every subagent reports completed.
6. Record the app-server process tree again.
7. Continue using the parent task and wait several minutes.
8. Observe that complete MCP launcher/worker groups created for the completed subagents remain alive.

The repeated suite in this reproduction included launchers for:

• Playwright MCP
• Context7
• Open Web Search
• Memory
• Sequential Thinking
• Fetch
• a bundled plugin bridge

The servers were initialized as a group even when a subagent did not call their tools.

What is the expected behavior?

After a task or subagent runtime completes, Codex should do one of the following:

• terminate the MCP process tree owned by that runtime;
• safely reuse a bounded shared MCP pool;
• start only the MCP servers actually needed by that runtime.

Repeated task/subagent use should return to a bounded baseline instead of accumulating complete subprocess suites. Codex diagnostics should also expose which task owns each MCP process group and whether that owner is still active.

Additional information

Timestamp correlation

Local timestamps from one controlled diagnostic session:

| Task event | MCP suite start |
|---|---|
| Parent task initialized at 13:39:52 | launcher roots at 13:39:53 |
| Subagent spawned at 13:55:53 | launcher roots at 13:55:58 |
| Subagent spawned at 13:56:49 | launcher roots at 13:56:57 |
| Subagent spawned at 13:57:17 | launcher roots at 13:57:22 |

Each new group contained the same launcher pattern. At least two older suite start groups no longer matched a live task/subagent visible during the snapshot, but remained children of the active app-server.

The suites created for the three diagnostic subagents were still present after those subagents returned completed results.

Controlled cleanup

A later cleanup selected only known MCP launcher roots that were direct children of the desktop app-server, recursively enumerated their descendants, and terminated descendants before roots. It explicitly protected ChatGPT.exe, codex.exe, the active shell, and unrelated user processes.

Immediately before cleanup, the remaining selected MCP trees contained 242 process-tree members and approximately 8.27 GB of private memory. After cleanup:

• MCP launcher roots after 3 seconds: 0
• MCP launcher roots after 10 seconds: 0
• matching node/cmd/uvx/python MCP aggregates: 0
• the Codex desktop app and active task remained running

This confirms that the retained MCP child trees were a major source of the process and memory footprint.

Configuration caveat

The original user configuration contained two equivalent Context7 entries. That was a local configuration mistake, not an upstream defect, and it amplified each suite by one server. The duplicate entry was removed and the TOML configuration was revalidated.

However, the lifecycle issue is independent of that duplicate: each task/subagent still received a complete multi-server suite, and completed runtimes did not reliably return to a bounded baseline.

Separate native exception

The same machine also encountered a Codex Micro native-module exception reported separately in #33529. Event timing did not correlate with MCP suite creation: new MCP batches matched task/subagent initialization timestamps, while many native exceptions occurred without creating a new batch. The issues are therefore reported separately.

Related issues

• #32694 — Windows App MCP/plugin groups scale with task runtimes
• #25015 — app-server leaks MCP stacks for subagents on Linux
• #28361 — Windows persistent app-server/MCP child process cleanup
• #20883 — project-scoped/shared MCP process pool proposal

Internal Codex Feedback ID:

no-active-thread-019f69aa-041b-7ea0-a3e2-f2f8f1e13028

No task contents, conversation text, local usernames, absolute user paths, credentials, or raw process command lines are included.