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

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?

1. Fully terminate the Codex App and verify that its previous Node/MCP processes have exited.

2. Start the Windows Codex App.

3. Observe the initial Node process population. In my reproduction it was approximately 7 processes.

4. Open the Zoyl project (U:\zoyl.local).

5. Create a NEW Codex chat/thread rather than continuing the old long-running thread.

6. Start one substantial Codex development/QA task.

7. Do not run PHPStorm or other development tools that could independently create Node processes.

8. While the Codex task runs, periodically inspect Windows processes.

9. 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

10. Allow the Codex task to finish.

11. 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:

1. 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.

2. PHPStorm was deliberately kept closed during the controlled diagnostics to eliminate it as a source of Node processes.

3. Process inspection showed the repeated Node/MCP processes were descendants of the Codex app-server process.

4. 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.

5. 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"

6. 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.

7. 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

Start with the controlled reproduction and inspect the Codex app-server process tree while comparing the attached 12-node-runtime-reproduction.txt and process snapshots. Focus on the named node_repl, Playwright MCP, Chrome DevTools MCP, watchdog, and MCP server processes. Done means one task no longer multiplies or retains hundreds of Codex-owned processes after completion, while the separate stale subagent display is investigated independently.