Repository navigation
Windows Codex App repeatedly creates and retains hundreds of duplicate Node/MCP processes during a single task #38825
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop / CLI 0.148.0-alpha.9
What subscription do you have?
ChatGPT Pro 200
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Windows Codex App repeatedly creates duplicate Node-based MCP/runtime process stacks during normal agent work and does not reclaim them when the task completes.
I reproduced this from a fresh Codex start and a new Zoyl project thread.
Fresh startup had approximately 7 Node processes. After running one Codex task in the new thread, the task completed with 284 Node processes present, 283 of which were attributable to Codex.
The post-task Node population included:
- 70 Chrome DevTools MCP processes
- 70 Playwright MCP processes
- 35 Chrome DevTools watchdog processes
- 35 Codex node_repl processes
- 30 mcp/server.bundle.mjs processes
- 30 mcp/server.mjs processes
- 2 other Node processes
The largest growth occurred during a five-minute portion of the task:
21:36 - 38 processes created
21:37 - 46
21:38 - 48
21:39 - 72
21:40 - 14
That is 218 Node processes created in approximately five minutes.
As the process count becomes large, Windows becomes noticeably slow and jerky. Fully terminating Codex removes the Codex-related Node population.
There is also a potentially related UI/session-state issue: historical subagent lists from old threads can reappear as "is working" even though those projects have no task running. However, investigation of the local rollout files found no new writes to those historical agent rollouts when they reappeared, so I have not concluded that those displayed historical agents are actually executing.
The reproducible performance problem is the repeated creation and retention of duplicate Node/MCP runtime stacks during active Codex work.
12-node-runtime-reproduction.txt
What steps can reproduce the bug?
-
Fully terminate the Codex App and verify that its previous Node/MCP processes have exited.
-
Start the Windows Codex App.
-
Observe the initial Node process population. In my reproduction it was approximately 7 processes.
-
Open the Zoyl project (U:\zoyl.local).
-
Create a NEW Codex chat/thread rather than continuing the old long-running thread.
-
Start one substantial Codex development/QA task.
-
Do not run PHPStorm or other development tools that could independently create Node processes.
-
While the Codex task runs, periodically inspect Windows processes.
-
Observe Codex repeatedly creating additional instances of:
- node_repl.exe
- @playwright/mcp
- chrome-devtools-mcp
- chrome-devtools-mcp watchdog
- mcp/server.mjs
- mcp/server.bundle.mjs
-
Allow the Codex task to finish.
-
Immediately after completion, count Node processes.
Result from my controlled reproduction:
- Fresh startup: approximately 7 Node processes
- During task at 21:33: 59 Node / 58 Codex-related
- Immediately after task completion: 284 Node / 283 Codex-related
Process creation was particularly rapid from 21:36 through 21:40, when 218 Node processes were created.
The new root rollout was:
01a0082d-b030-77f2-b130-64276b418c3d
It was a new user thread with cwd U:\zoyl.local.
Only one newly created guardian subagent was found in the post-restart session files:
01a00837-b0dd-70b1-8589-6dd13dfb5dda
Despite this, hundreds of local Node/MCP processes accumulated.
Fully terminating Codex removes the Codex-related Node processes.
What is the expected behavior?
Codex should reuse or properly dispose of its local MCP/runtime infrastructure.
Running one Codex task should not cause hundreds of duplicate Playwright MCP, Chrome DevTools MCP, node_repl, watchdog, and MCP server processes to accumulate.
When a task or subagent finishes, runtime processes that are no longer required should terminate promptly.
A completed Codex task should return the local runtime population to a reasonable idle baseline instead of leaving hundreds of Codex-owned Node processes running and degrading Windows performance.
Historical completed subagents should also not be displayed as "is working" when no corresponding task is active.
Additional information
Additional observations from investigation:
-
The issue was initially observed across several projects (Zoyl, TikNik and YALPS), sometimes with more than 100 Node processes. The controlled reproduction subsequently produced 284 Node processes from one fresh Zoyl thread.
-
PHPStorm was deliberately kept closed during the controlled diagnostics to eliminate it as a source of Node processes.
-
Process inspection showed the repeated Node/MCP processes were descendants of the Codex app-server process.
-
A clean idle test was performed with Codex open but untouched for approximately 12 minutes. No new MCP/Playwright/Chrome DevTools processes were created during that idle interval. The explosive process creation occurs during Codex activity.
-
Historical subagent UI state also appears incorrect. Examples observed:
- old Zoyl thread: 73 subagents shown as "is working"
- TikNik: 30 shown as "is working" with no task running
- older YALPS thread: 102 shown as "is working" with no task running
- PosterFrom: 3 shown as "is working" despite no work there for days
- current YALPS thread correctly showed one subagent as "done"
-
When these historical agents reappeared, their old rollout JSONL files did NOT receive new modification timestamps. This suggests the stale "is working" display may be a separate UI/session-state issue rather than all of those historical agents actually executing.
-
Token usage was investigated because my ChatGPT Pro Codex allowance has been depleting faster than expected. I have NOT established that the stale historical subagents are consuming tokens.
For the controlled new Zoyl thread, the final token record reported:
- input_tokens: 9,075,276
- cached_input_tokens: 8,862,464
- output_tokens: 19,587
- reasoning_output_tokens: 4,761
- total_tokens: 9,094,863
- model_context_window: 258,400
- weekly rate limit used: 53%
Because most input tokens were cached and the historical rollouts were not being modified, I am reporting unexpected usage only as a concern requiring investigation, not as a confirmed consequence of the stale subagent state.
The immediate reproducible defect is the extreme multiplication and retention of Codex-owned Node/MCP processes on Windows.
09-reactivation-process-snapshot.csv
10-reactivated-session-files.csv
Activity
github-actions commentedon Aug 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
enabled = falseis ignored #37672Powered by Codex Action
ScottKemp commentedon Aug 16, 2026
I reproduced this on Windows with additional app-server evidence.
Environment:
After restarting the desktop app, it generated 15 distinct thread/start
requests in approximately 15 seconds, despite there being only one visible
active task.
Every hidden thread immediately entered session_init.mcp_manager_init and
launched another set of 9–15 configured STDIO MCP servers.
Observed process growth:
PowerShell.MCP.Proxy, python, and python3.12
The thread/start records had dynamic_tool_count=0. This indicates the desktop
app is creating multiple hidden sessions and initializing the entire MCP set
for each one—not that one MCP server is independently reproducing.
Historical logs generally showed one initialized thread at a time. After the
August 15 desktop update, the logs show bursts of 18 and 15 initialized
threads.
Project AGENTS.md instructions do not appear causal: the desktop app emits
thread/start and begins MCP initialization before the model performs any
instruction-driven work.
Expected behavior:
In-app feedback session ID:
019c0d37-d2b6-74c0-918f-0e64af9b6e14
zoylllc commentedon Aug 18, 2026
I will look into what I can test when time is available. At current I am using codex in a very long running set of processes that may take another two days to finish.
In the meantime, I have found that the issue is acting somewhat random, I will need to dig more to find the pattern, where not every prompt or restart of the application is causing the issue then randomly during testing/validation I will go from an expected ten or so node processes to 100+.
I have also seen, not fully substantiated yet, but there may also be a partial correlation to burning through tokens at an accelerated rate commensurate to the prompt work being performed.
zeel01 commentedon Sep 3, 2026
I'm currently needing to restart the Codex app every 30-60 minutes because as far as I can tell, the process tree just keeps growing until the app server stops responding.
It looks like every task is running its own copy of every MCP/plugin server, even ones they aren't/have never used. Plus there's loads of unidentifiable process proliferation. And the process tree blooms back pretty fast after a restart, I think restarting it mainly just reclaims some memory and releases anything that was stuck.
But there doesn't appear to be any intelligent sub-process management going on, everything gets a new process and rarely if ever do any of those processes get terminated even when they aren't needed anymore or aren't needed to start with.
genew1970 commentedon Sep 27, 2026
Additional reproduction/data point from Windows Codex Desktop:
OpenAI.Codex 26.924.1866.0node.exeinstances one at a time.I have not yet identified which exact Node PID/runtime instance caused the transition, so this does not prove Node itself is the root cause. However, the immediate UI/task-state change after terminating a Node child process suggests the app may be waiting on a child-process lifecycle event, IPC channel, stdout/stderr close, MCP/runtime shutdown, or similar completion/cleanup condition.
This may be related to the retained Node/MCP process behavior already described in this issue.
A useful next reproduction would be to capture the PID, parent PID, command line, CPU/memory, and child process tree before terminating each Node instance, then identify whether terminating one specific runtime consistently causes Codex to recognize task completion.