Windows Codex App repeatedly creates and retains hundreds of duplicate Node/MCP processes during a single task

Open 💬 4 comments Opened Aug 16, 2026 by zoylllc

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

11-new-session-summary.txt

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

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 12 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#38754
#38693
#38714
#37672

Powered by Codex Action

ScottKemp · 11 days ago

I reproduced this on Windows with additional app-server evidence.

Environment:

Codex Desktop package: 26.810.7004.0
Desktop app-server client: 26.810.52044
Bundled Codex: 0.148.0-alpha.9
13 enabled STDIO MCP servers
Suggested prompts disabled

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:

248 → 583 processes in 195 seconds
Later reached 617 processes
Approximately 265 node.exe and 261 cmd.exe processes
15 copies each of google-ads-mcp, node_repl,

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:

One MCP runtime set per active user task, or shared/reused MCP runtimes.
Hidden or ambient tasks should skip MCP initialization and be torn down.
Disabling Suggested prompts should prevent related ambient task creation.

In-app feedback session ID:
019c0d37-d2b6-74c0-918f-0e64af9b6e14

shleder · 11 days ago

Your report is useful for codex-rescue field validation on the persisted side of the stale-subagent/process problem. The tool won’t fix Node/MCP process spawning or reaping; I want to test whether the local session tree shows stale/unfinished evidence and whether diagnosis stays conservative when runtime lifecycle and persisted state disagree.

If you still have the affected Codex home, could you start with:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

If the latest session is not the affected one, sessions output alone is still useful for discovery behavior. Please don’t run recovery solely to test the process leak.

Sanitized output + versions/exit codes only, please—no raw rollouts/SQLite, prompts, credentials, process dumps with private paths, or unredacted home paths. Repo: https://github.com/shleder/codex-rescue

zoylllc · 9 days ago

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.