Windows Desktop app-server repeatedly spawns duplicate MCP stdio process pools (183 node.exe / 13GB private memory)

[xxH7r]

Summary

Codex Desktop on Windows repeatedly starts duplicate stdio MCP process pools under codex.exe app-server --analytics-default-enabled. The duplicate cmd -> npx/npx.cmd -> node.exe trees are not consistently reaped, causing large memory growth.

This appears related to:

• Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time) #28361
• MCP server processes leak: per-thread processes never cleaned up (9+ GB RSS) #30408
• Windows Desktop 26.623 starts duplicate MCP pools after RefreshMcpServers on hidden thread #30753
• Codex Desktop on Windows leaves Node/MCP helper processes alive until memory pressure makes PC unresponsive #29079

I am filing a separate report because this reproduces on the current Windows Desktop app installed on my machine, and the process count/memory growth is severe enough to affect normal use.

Environment

• OS: Microsoft Windows 11 Home Chinese, 64-bit
• OS version/build: 10.0.22621 / build 22621
• Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex Desktop version: 26.527.3686.0
• ~/.codex/version.json: latest_version is 0.142.5
• App server command observed:
  • codex.exe app-server --analytics-default-enabled

Global MCP servers configured in ~/.codex/config.toml:

• reactbits: npx -y reactbits-dev-mcp-server
• tavily: npx.cmd -y tavily-mcp
• chrome-devtools: npx chrome-devtools-mcp@latest
• shadcn: npx.cmd -y shadcn@latest mcp
• figma: HTTP MCP
• node_repl: bundled Codex node_repl

No secrets are included here.

Observed Behavior

During normal Codex Desktop usage, Task Manager showed a large number of node.exe processes consuming substantial memory.

Read-only process inspection showed:

• Peak observed: 183 node.exe processes
• Peak private memory: 13.2 GB
• Peak working set: 10.92 GB
• One old Desktop app-server process tree owned about 170 of the node.exe descendants and about 12.24 GB private memory

The duplicated processes were primarily repeated MCP stdio server trees:

• tavily-mcp
• reactbits-dev-mcp-server
• shadcn@latest mcp
• chrome-devtools-mcp@latest
• chrome-devtools-mcp watchdog children

Representative command lines:

"node" "...\\npm-cache\\_npx\\...\\chrome-devtools-mcp\\build\\src\\bin\\chrome-devtools-mcp.js"
node.exe ...\\chrome-devtools-mcp\\build\\src\\telemetry\\watchdog\\main.js --parent-pid=...
"node" "...\\npm-cache\\_npx\\...\\shadcn\\dist\\index.js" mcp
"node" "...\\npm-cache\\_npx\\...\\tavily-mcp\\build\\index.js"
"node" "...\\npm-cache\\_npx\\...\\reactbits-dev-mcp-server\\dist\\index.js"

After I only inspected the process tree, without killing any process and without changing config, the old app-server appears to have exited/restarted and the count dropped to:

• 19 node.exe processes
• about 1.5 GB private memory

However, shortly afterward, the count started increasing again:

• 37 node.exe processes
• 2.89 GB private memory
• 2.91 GB working set

Breakdown at that point:

chrome-devtools: 12 processes, 1.22 GB private
shadcn:           8 processes, 0.68 GB private
reactbits:        8 processes, 0.49 GB private
tavily:           8 processes, 0.47 GB private
codex-node:       1 process,  0.02 GB private

This suggests the duplicate MCP pools are still being created after the old high-memory app-server tree is cleaned up.

Expected Behavior

Codex Desktop should not create unbounded duplicate MCP stdio process pools.

At most one active MCP process pool should exist per owning active session/thread, and MCP child processes should be reliably cleaned up when the owning session/thread/app-server lifecycle ends.

Actual Behavior

The Desktop app-server creates multiple full MCP stdio process pools. Those pools accumulate under the app-server and can grow to hundreds of node.exe processes and more than 10 GB of memory.

In my case, the leak/duplication was visible without any project dev server being involved. The repeated processes came from Codex MCP startup, not from application code.

Impact

This makes Codex Desktop risky to keep open for long sessions on Windows when several stdio MCP servers are configured. Memory growth can become large enough to degrade the machine and force users to manually kill processes or restart Codex.

Notes

This looks especially close to #28361 and #30753:

• Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time) #28361 describes Windows app-server/MCP children not being reaped and accumulating to hundreds.
• Windows Desktop 26.623 starts duplicate MCP pools after RefreshMcpServers on hidden thread #30753 describes Windows Desktop creating duplicate MCP pools after RefreshMcpServers on a hidden thread.

The extra data point here is that I observed both behaviors in one session:

1. a very large old app-server tree with around 170 duplicate node.exe descendants;
2. automatic cleanup/restart reducing the count;
3. new duplicate MCP pools appearing again afterward.

[github-actions]

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

• Windows Desktop 26.623 starts duplicate MCP pools after RefreshMcpServers on hidden thread #30753
• MCP server processes leak: per-thread processes never cleaned up (9+ GB RSS) #30408

Powered by Codex Action

[xxH7r]

Warning: a user posted codex_mcp_fix.zip in this thread. My browser/Windows security flagged it as malicious. Please do not download or run it. Maintainers may want to remove that comment/attachment.

[mayank6091]

@xxH7r This feels like one of those issues where process metrics alone won't explain the root cause. For long-running agent workflows, it's useful to capture an execution timeline that correlates MCP server lifecycle events, tool invocations, and process creation. That makes it much easier to identify whether duplicate pools are caused by orchestration retries, MCP reconnects, or process management itself.