Skip to content

Codex CLI multi-agent spawns duplicate Serena MCP instances instead of sharing one connection #12333

Closed as not planned

Description

@ginishuh

What version of Codex is running?

codex-cli 0.104.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

WSL2 Ubuntu on Windows 11

What issue are you seeing?

When using Codex CLI with Serena MCP enabled, multi-agent / multiple active Codex sessions appear to spawn separate Serena MCP server processes instead of reusing a shared connection.

In practice, this creates many duplicate serena start-mcp-server and language-server child processes, which significantly increases memory usage over time.

This feels especially expensive for Serena, because each MCP server can spawn heavyweight language server processes (e.g., Dart language server).

What steps can reproduce the bug?

  1. Configure Serena MCP in ~/.codex/config.toml, e.g.
[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex", "--transport", "stdio", "--enable-web-dashboard", "false"]
  1. Start Codex CLI and run tasks that involve multi-agent usage (or keep multiple Codex sessions active).
  2. Observe processes with:
ps -eo pid,ppid,rss,cmd | rg 'serena start-mcp-server|\.serena/language_servers|codex'
  1. After some activity, multiple Serena server instances accumulate, each with additional language-server children.

What is the expected behavior?

  • Child agents should reuse the parent MCP connection when possible (or at least pool/reuse by session/project), rather than launching a new Serena MCP server per agent/session.
  • MCP process growth should be bounded and predictable.

Additional information

Observed sample from one run:

  • serena start-mcp-server total: 23 processes
    • owner breakdown in that snapshot:
      • codex: 19
      • claude: 2
      • droid: 2
  • Serena-related total (serena + .serena/language_servers) reached ~5.3 GB RSS in that snapshot.

For Codex-owned processes, parent chain looked like:

codex resume -> uvx ... serena start-mcp-server -> sh -> dart language-server

So this looks like process-level MCP duplication rather than a single shared MCP connection for sub-agents.

Related context (different but adjacent): #7281, #9989 are extension/WSL process/cwd issues. This report is specifically about Codex CLI multi-agent MCP connection sharing / process duplication.

Activity

  1. added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    mcp-serverIssues related to the use of the `codex mcp-server` subcommand
    on Feb 20, 2026
  2. ginishuh commented on Feb 20, 2026

    @ginishuh
    Author

    Additional clarification:

    This appears to be broader than Serena specifically.

    From observation, the duplication pattern seems to affect MCP servers configured via command (stdio transport) in general, because each active agent/session can spawn its own MCP subprocess.

    So Serena likely makes the impact more visible (because it can fan out into heavyweight language-server child processes), but the underlying behavior looks like a stdio MCP lifecycle / sharing issue rather than a Serena-only bug.

    By contrast, MCPs configured via url (streamable-http / sse) are naturally easier to share across agents/sessions because they can point to a single long-lived external server endpoint.

    If useful, I can also provide snapshots showing this behavior with non-Serena stdio MCP entries as a follow-up.

  3. ginishuh commented on Feb 20, 2026

    @ginishuh
    Author

    Linked follow-up feature request for lifecycle behavior: #12335 (auto-close completed/idle agents + teardown unused MCP clients).

  4. etraut-openai commented on Feb 20, 2026

    @etraut-openai
    Contributor

    Thanks for the bug report, but this is by design. Each subagent can potentially have different MCP configurations, so each requires its own MCP server instances.

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

    CLIIssues related to the Codex CLIbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversmcp-serverIssues related to the use of the `codex mcp-server` subcommandwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions