[Windows 26.818] MCP process-batch accumulation and incomplete cleanup still reproducible with 5 MCP servers

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex_26.818.8289.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0, x64

What issue are you seeing?

Codex Desktop repeatedly launches complete or near-complete sets of configured stdio MCP servers during ordinary task activity. Older MCP process trees remain alive instead of being reclaimed, causing cmd.exe and node.exe processes and their memory usage to accumulate over the lifetime of the Desktop session.

The affected configuration contained five Node/npx-based MCP servers: Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools. Some were configured directly, while Playwright and Chrome DevTools were supplied by plugins, so the behavior does not appear specific to one MCP package.

The observed Windows process chain was:

codex.exe app-server
  -> cmd.exe /c npx ...
     -> npx.cmd
        -> cmd.exe /d /s /c ...
           -> node.exe

The child processes appeared in distinct start-time batches: one around 13:56 and several more around 15:56–15:59.

A process-tree snapshot attributable to the live Codex app-server contained approximately:

• 30 cmd.exe processes
• 34 node.exe processes
• ~3.7 GB combined working-set memory

The same MCP server names occurred repeatedly across the batches. Completing or closing the visible task did not reclaim the older process trees. The wrappers also caused visible cmd.exe console-window flashes on Windows.

Disabling MCP entries in config.toml did not terminate already-running children. A full Codex Desktop tray exit/restart was required before the reduced MCP configuration took effect.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows with multiple stdio MCP servers configured. In my case these included Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools.
2. Use Codex Desktop normally across multiple tasks/session activity while leaving the Desktop app running.
3. Inspect the process tree of the active codex.exe app-server in Task Manager or PowerShell.
4. Observe multiple start-time batches containing repeated instances of the same MCP servers under cmd.exe / npx.cmd / node.exe.
5. Complete or close the visible Codex task and inspect the process tree again.
6. The older MCP process trees remain alive rather than being reclaimed.
7. Disable manually configured MCP entries in config.toml.
8. Observe that already-running MCP children remain alive.
9. Fully exit Codex Desktop from the system tray and restart it.
10. The stale processes from the previous app-server generation are finally removed.

In my observed incident, the live app-server process tree accumulated approximately 30 cmd.exe processes and 34 node.exe processes, using about 3.7 GB of combined working-set memory.

What is the expected behavior?

Codex Desktop should keep the number of MCP server processes bounded.

When an MCP connection manager/runtime generation is replaced, the previous MCP server set should be shut down and the complete Windows process tree should be reaped, including cmd.exe-wrapped node.exe grandchildren.

Completing tasks or disabling MCP servers should not leave stale MCP process trees alive.

Background MCP wrappers should also launch without visible cmd.exe console windows.

Additional information

This appears closely related to #32797, #34614, and #38825.

I am filing this as a separate current-build reproduction because the same process-batch accumulation and incomplete cleanup behavior is still reproducible on the newer Codex Desktop package OpenAI.Codex_26.818.8289.0.

Unlike #32797, which reports a much larger MCP configuration, my affected setup contained only five Node/npx-based MCP servers (Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools). Despite the smaller configuration, the live Codex app-server process tree still accumulated approximately 30 cmd.exe processes and 34 node.exe processes, using about 3.7 GB of combined working-set memory.

The processes appeared in distinct start-time batches, with the same MCP server names recurring across batches. Completing the visible task did not reclaim the older process trees. Disabling MCP entries in config.toml also did not terminate already-running children; a full Codex Desktop tray exit/restart was required before the reduced configuration took effect.

The bundled Codex version observed from the Desktop process was 0.149.0-alpha.4.3. A separate codex executable exists on my PATH, but it is not the Desktop-bundled binary and was not used as the Desktop version reported above.

I can provide a fresh sanitized process snapshot containing PID, PPID, process name, sanitized command line, start time, and working-set memory if useful for identifying which app-server/runtime generation owns each stale MCP process tree.

I have intentionally not attached my full config.toml for security reasons.

Start with the app-server and MCP connection manager/runtime-generation paths, using the Windows reproduction steps and process-tree snapshot described here. Check how config.toml changes, task completion, and runtime replacement affect the cmd.exe/npx.cmd/node.exe tree. Done means repeated MCP batches are reclaimed, process counts stay bounded, disabled servers terminate, and wrappers do not flash console windows.