Repository navigation
[Windows App 26.707.9981.0] MCP suites persist after subagents complete, reaching 10.9 GB private memory #33531
Description
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?
- Configure several global stdio MCP servers in
~/.codex/config.toml. - Launch the Codex Windows App and start one task.
- Record the direct children and descendants of the desktop app-server
codex.exe. - Spawn multiple subagents for bounded tasks that do not need most of the configured MCP tools.
- Wait until every subagent reports
completed. - Record the app-server process tree again.
- Continue using the parent task and wait several minutes.
- 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/pythonMCP 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
- [App/Windows] MCP/plugin subprocess groups scale linearly with active task runtimes #32694 — Windows App MCP/plugin groups scale with task runtimes
- 🩹 Codex app-server leaks MCP process stacks for subagents, causing linear memory growth on Linux #25015 — app-server leaks MCP stacks for subagents on Linux
- Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time) #28361 — Windows persistent app-server/MCP child process cleanup
- Codex Desktop should use a project-scoped MCP process pool instead of starting MCP per session #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.
Activity
github-actions commentedon Jul 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chenxupeng1990-eng commentedon Jul 16, 2026
Independent reproduction on a newer Microsoft Store build:
OpenAI.Codex_26.707.12708.0_x64.After a fresh desktop restart, switching/resuming three existing tasks produced three repeated MCP/plugin runtime batches:
node.exechildrennode_repl.exechildrenAll 15 processes were direct children of the same long-running desktop
codex.exe app-server. The older batches were still resident when the third batch appeared. No new subagents were started during this controlled pass, and the resumed tasks had not intentionally invoked those plugin MCP tools before the batches appeared.Additional observations from the same clean run:
mcpServerStatus/list: 22,231 msplugin/list: up to 10,496 msgit pullorgit fetchcommands during the reproductionA controlled cleanup can return the matching MCP child count to zero without stopping the desktop app, but later task initialization recreates the suites. This reproduces the lifecycle/ownership defect on build
26.707.12708.0, beyond the26.707.9981.0build reported here.No task text, usernames, credentials, raw command lines, or absolute paths are included.
aidawilliam41-ops commentedon Jul 19, 2026
Additional Windows evidence on newer builds confirms that cleanup occurs, but does not keep the MCP runtime population bounded.
Environment:
OpenAI.Codex 26.715.4045.026.715.319250.145.0-alpha.18Observed:
node_replplus Tavily, Figma, Morph, GitHub, shadcn, Valyu, Firecrawl, and two internalserver.mjsroots.This disproves the strongest wording that nothing is ever cleaned up. The narrower result is that cleanup is partial and does not reliably return the runtime to a bounded baseline while old and new complete suites coexist.
Telemetry limitation:
Desktop logs expose task/turn activity, but not MCP PID-to-task ownership, reference counts, reuse decisions, or cleanup-completion events. Therefore I cannot identify the exact owner of each surviving suite or claim that every survivor is permanently orphaned.
Expected:
MCP runtimes should be reused, started lazily, or deterministically released so repeated task/subagent activity returns to a bounded baseline. Diagnostics should expose runtime ownership and cleanup state.
Actual:
Complete suites are repeatedly created near task/subagent activity and remain concurrently resident long enough to retain multiple gigabytes of memory.
No task content, local paths, usernames, credentials, or raw command lines are included.
aidawilliam41-ops commentedon Jul 22, 2026
Full-TTL correction and stock-cleanup evidence on a newer Windows build
Environment:
26.715.9868.00.145.0-alpha.30A 95-minute read-only observer captured two complete stock delayed-cleanup sequences. No Codex, MCP, or Windows process was terminated manually by the observer.
Sequence 1:
thread/unsubscribereturnedstatus=unsubscribedat 11:58:50.230taskkillchildren appeared at 12:28:51–12:28:52taskkill: 1801.076 secondsSequence 2:
thread/unsubscribereturnedstatus=unsubscribedat 12:46:15.022taskkillchildren appeared at 13:16:15–13:16:17taskkill: 1800.691 secondsThis confirms that the stock delayed-cleanup path does execute and that complete MCP populations can turn over. It disproves blanket wording that cleanup never runs or that every retained suite is necessarily a permanent orphan.
Important limits:
taskkillexit status is not surfaced.active=falseanchor after the observation began. Therefore its own end-to-end cleanup path was not exercised, and the exclusive-owner test is classified as blocked rather than passed.The corrected product concern is therefore narrower: cleanup exists, but retention is long and overlapping populations can remain resident for substantial periods while new suites are created. The unresolved gaps are bounded-baseline behavior, exact ownership, cleanup acknowledgement, and whether every eligible completed owner is eventually released.
No task content, usernames, absolute paths, credentials, raw command lines, or private logs are included.
luvs01 commentedon Aug 7, 2026
Additional Windows Desktop timing evidence records a close temporal correlation between one read-only subagent start and a matching direct app-server Node child.
Environment (operator-recorded; the attachment does not encode the package version)
OpenAI.Codex AppX: 26.730.8199.0
The parent app-server remained unchanged.
The read-only subagent was created at 2026-08-06 04:08:04.492 UTC.
A new matching direct app-server Node child started at 04:08:04.907 UTC, 0.414858 seconds later.
Its sanitized executable and command identity matched the other direct Node children.
The event record reports no MCP tool call by that subagent before it was subsequently interrupted.
The same child was still present at the final A2 sample, at least 273.816 seconds after creation. The four matching children then totaled 299.3 MiB private.
A later readback at 05:04:26.517 UTC found all four relevant children still present, including the subagent-correlated child, 56.36 minutes after its start; their individual private-memory values ranged from 74.2 to 76.1 MiB.
This is consistent with the reported lifecycle problem, while the artifact establishes persistence and close timing for a matching direct Node child, not a complete MCP suite or definitive process ownership.
Expected behavior: a canceled or completed subagent should release its owned runtime, attach to a bounded shared pool where safe, or expose its documented grace-period owner and teardown deadline. A diagnostic mapping from agentThreadId to process-group identity would make this verifiable without raw command lines.
Sanitized event-partition JSON — SHA-256
f2ed34a65e92db8dd6a0c78229f2c74a49d038d2b73355c73b1431bea235a5b8The aggregate A1/A2 tables are attached once in the related #20883 evidence comment rather than duplicated here.
SergeyPomelov commentedon Aug 16, 2026
Reproduced on Windows with ChatGPT/Codex Desktop 26.810.7004.0 the best flagship vibecoded application.
Task Manager showed 253 ChatGPT processes using 8.1 GB RAM. Shortly afterward, there were 139 node.exe processes using 12.5 GB, mostly repeated MCP servers such as GitLab, Jira, Confluence, and Chrome DevTools.