Codex spawning too many mcp instances and never kills them, memory is getting overwhelmed

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

• #14233
• #13680
• #13947

Powered by Codex Action

yeah, I make the same issue.. Can't work in multi-agent mode, 30 RAM + 20 Swap with 4 codex cli 🗡️ 💃

If you disable subagents (in experimental functions), everything will work. I recommend doing that for now; we're waiting for the openAI team to confirm the decision. @VladimirBrejcha

<img width="2032" height="1162" alt="Image" src="https://github.com/user-attachments/assets/94000664-b3f8-4d6e-b19e-7496632bdae2" />

this is getting too far

I even disabled subagents but that didn't really change a thing

Same build, same macOS, and not only subagents

@VladimirBrejcha i hit this on the exact same build and platform. @rldyourmnd mentioned multi-agent load, but on my side this also happened with ordinary conversations over time.

My setup

• Codex.app 26.311.21342 (build 993)
• macOS Darwin 25.3.0, Apple Silicon
• app was open about 2.5 days
• about 18 conversations/tasks in that time
• MCPs: context7, playwright, chrome-devtools, webflow mcp-remote, custom Python MCP

What the buildup looked like

~100 Node processes
22 Python (B12) processes
~5 MCP servers per conversation
18 conversation generations x ~5 MCPs = ~90 stale MCP processes

So at least on my machine this was not just "subagents went wild". Each finished conversation was leaving a full MCP bundle behind.

I also tried the quit and reopen cleanup path. It killed most of the big pile, but not all of it:

Cmd+Q cleanup:
- about 90 Codex child processes died
- 2x orphaned `chrome_crashpad_handler` remained
- 2x orphaned `playwright-mcp` remained
- 1x orphaned `twitterapi` MCP remained

The old survivors matched Codex sessions from March 9, 2026 and March 14, 2026.

So for me this feels like a real lifecycle cleanup bug, not just a heavy RAM usage side effect. I also had active Claude Code sessions on the same machine and those cleaned up normally, so this did not look like a generic macOS resource issue.

I also agree with the framing from #12333 / #14233: i am not asking for one shared MCP instance for all active work. The bug is that finished work is not converging back to a sane baseline.

I can reproduce the Linux CLI/job-control variant of this on the current stable CLI as well.

Environment

• codex-cli 0.139.0
• Linux CLI on Ubuntu, zsh, running under tmux/PTY sessions
• MCP servers enabled, including serena, playwright-mcp, and mcp-server-puppeteer

Reproduction

1. Start codex --dangerously-bypass-approvals-and-sandbox in a terminal.
2. Wait until MCP servers are initialized.
3. Press Ctrl+Z.
4. Run ps -t <pts> -o pid,ppid,pgid,sid,tpgid,stat,etime,cmd.
5. Optionally start a second codex in the same shell before resuming the first one.

Observed behavior

After Ctrl+Z, the Codex wrapper/native processes are stopped, but the MCP child processes keep running in separate process groups:

node .../bin/codex                                      Tl
.../vendor/.../bin/codex                               Tl
uv tool uvx ... serena start-mcp-server --context codex Sl
npm exec @playwright/mcp@latest ...                     Sl
npm exec @modelcontextprotocol/server-puppeteer         Sl
node .../playwright-mcp --browser chrome ...            Sl
node .../mcp-server-puppeteer                           Sl

If I then start another codex in the same shell, the PTY ends up with one stopped Codex process group plus one active Codex process group, while the old MCP server processes are still alive. This matches the accumulation pattern described here and in #16256, but on 0.139.0 rather than older CLI builds.

The foreground process group also confirms the layering pattern: after starting the second Codex, the TTY foreground TPGID belongs to the new Codex, while the previous Codex remains Tl and its MCP children remain Sl.

Why this seems to happen

This looks like a process lifecycle/job-control issue rather than only subagent behavior. SIGTSTP stops the Codex process group, but MCP stdio servers are spawned into independent process groups and are not stopped or torn down with the suspended session.

Suggested direction

A robust fix probably needs MCP subprocess lifecycle management in the CLI/native side, for example:

• track MCP server process groups per Codex session;
• on normal exit/signals, gracefully terminate MCP process groups and escalate after a timeout;
• on SIGTSTP, either suspend/terminate the MCP process groups consistently before the parent stops, or make resume (SIGCONT) reconcile MCP state explicitly;
• add a regression test that starts a disposable stdio MCP command, suspends the CLI process group, and asserts no stale MCP processes are left when a second session is started or the first session exits.

For now, using tmux detach instead of terminal Ctrl+Z avoids triggering this, because the Codex process is not suspended.