Skip to content

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

Open
Open
Codex spawning too many mcp instances and never kills them, memory is getting overwhelmed#14548
Labels
bugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformance

Description

@VladimirBrejcha
VladimirBrejcha
opened on Mar 13, 2026

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

Version 26.311.21342 (993)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Image Image

Codex is spawning more and more MCP server instances. Maybe it's subagents, maybe not.
Anyways, they are spawned and never killed, taking all the memory.

What steps can reproduce the bug?

Uploaded thread: 019ce516-facd-7543-bebd-44a8abf7b5df

What is the expected behavior?

No response

Additional information

No response

Activity

  1. VladimirBrejcha
    added
    appIssues related to the Codex desktop app
    on Mar 13, 2026
  2. github-actions
    added
    bugSomething isn't working
    mcpIssues related to the use of model context protocol (MCP) servers
    on Mar 13, 2026

  3. github-actions commented on Mar 13, 2026

    @github-actions
    github-actionsbot
    on Mar 13, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. rldyourmnd commented on Mar 13, 2026

    @rldyourmnd
    rldyourmnd
    on Mar 13, 2026

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

  5. rldyourmnd commented on Mar 13, 2026

    @rldyourmnd
    rldyourmnd
    on Mar 13, 2026

    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

  6. VladimirBrejcha commented on Mar 15, 2026

    @VladimirBrejcha
    VladimirBrejcha
    on Mar 15, 2026
    Author
    Image

    this is getting too far

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

  7. dorukardahan commented on Mar 17, 2026

    @dorukardahan
    dorukardahan
    on Mar 17, 2026

    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.

  8. etraut-openai
    removed
    appIssues related to the Codex desktop app
    on Mar 30, 2026
  9. etraut-openai
    marked MCP sub-agent processes are never terminated when codex sessions are stopped/suspended #16256 as a duplicate of this issue on Mar 30, 2026
  10. etraut-openai
    added
    performance
    on May 3, 2026

  11. de-monkey-v commented on Jun 15, 2026

    @de-monkey-v
    de-monkey-v
    on Jun 15, 2026 – with ChatGPT Codex Connector

    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.

  12. xmasterg commented on Sep 11, 2026

    @xmasterg
    xmasterg
    on Sep 11, 2026

    Commenting for this crazy bug's awareness.

    This is opened since MARCH 😄 This is a major issue!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions