Codex CLI 0.112.0: long-lived multi-agent sessions accumulate duplicate stdio MCP stacks instead of returning to a bounded baseline

What version of Codex CLI is running?

codex-cli 0.112.0

What subscription do you have?

Logged in with ChatGPT. Plan tier does not appear relevant to the reproduction.

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.17.0-14-generic x86_64 unknown

What terminal emulator and version are you using (if applicable)?

WezTerm 20240203-110809-5046fc22

What issue are you seeing?

In long-lived Codex CLI sessions with multi-agent enabled, the root Codex process appears to accumulate repeated stdio MCP launcher children over time instead of returning to a small bounded baseline after subagents finish.

I want to be precise about the distinction from earlier reports:

• I am not filing this to argue that all active subagents must share one MCP connection.
• I have read #12333, where a maintainer said separate MCP instances while subagents are active can be by design because subagents may need different MCP configs.
• The problem I am reporting here is lifecycle/teardown: in my environment the number of stdio MCP stacks keeps growing under the same long-lived root Codex PID, and many of those stacks remain alive well after the subagent work that caused them should be over.

This is reproducible enough that it causes real system pressure.

Current local setup includes these stdio MCP servers in ~/.codex/config.toml:

• serena
• chrome-devtools
• shadcn
• sequential-thinking

and features.multi_agent = true.

On 2026-03-11, during a fresh investigation on 0.112.0, I had 2 normal long-lived Codex CLI terminals open. The investigation itself was a third Codex session, so the snapshot below shows 3 live Codex root processes total.

Across those 3 live Codex roots, the machine had:

• 38 Serena-related processes
• 38 sequential-thinking processes
• 20 shadcn MCP processes
• 74 chrome-devtools processes

More importantly, the older root Codex PIDs each had many direct repeated stdio MCP launcher children:

• root Codex PID 5565: 7 Serena + 7 chrome-devtools + 7 shadcn + 7 sequential-thinking launcher children
• root Codex PID 24155: 10 Serena + 10 chrome-devtools + 10 shadcn + 10 sequential-thinking launcher children
• current investigation Codex PID 669004: 2 of each

So this does not look like “one MCP stack per currently active root session”. It looks like repeated MCP launcher growth under the same root Codex process over time.

Serena makes the impact especially visible in my environment because each duplicated Serena instance is started with web dashboard enabled. At the same snapshot, Serena dashboards were listening on:

• 127.0.0.1:24282
• 127.0.0.1:24283
• ...
• 127.0.0.1:24299

That is 18 concurrent Serena dashboard listeners from the accumulated instances.

There is also a secondary reliability problem that makes the impact worse in my setup: when Serena is activated against a very broad root (/home/<user> in my case), one duplicated Serena instance spent 7 minutes 11.5 seconds walking the home directory and then failed inside browser cache state:

FileNotFoundError: [Errno 2] No such file or directory: '/home/rldyourmnd/.config/browser-os/Default/WebStorage/7/CacheStorage/5e98ca14-d511-4c08-ad86-fcb4120e14b2'

I do not think that FileNotFoundError is the primary Codex bug here, but duplicated/stale Serena stacks make hitting this kind of expensive failure mode much easier.

What steps can reproduce the bug?

1. Configure several stdio MCP servers in ~/.codex/config.toml.
2. Enable multi-agent:

[features]
multi_agent = true

1. Keep one or more Codex CLI sessions alive for a while.
2. Let Codex spawn subagents repeatedly during normal work.
3. After those subagents have finished, inspect the process tree of the still-running root Codex PID.
4. Observe that repeated stdio MCP launcher children continue to accumulate under the same root PID.

A representative config shape for the affected stdio MCPs is:

[mcp_servers.sequential-thinking]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-sequential-thinking"]

[mcp_servers.shadcn]
command = "npx"
args = ["-y", "shadcn@latest", "mcp"]

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]

My Serena entry is wrapped in /usr/bin/bash -lc ... so it can populate DBUS_SESSION_BUS_ADDRESS, WAYLAND_DISPLAY, and DISPLAY before running:

uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context codex --enable-web-dashboard true --open-web-dashboard true

Commands I used to verify the issue:

codex --version
codex mcp list
ps -eo pid,ppid,cmd | rg '/vendor/x86_64-unknown-linux-musl/codex/codex|serena start-mcp-server|chrome-devtools-mcp|shadcn@latest mcp|server-sequential-thinking'
ss -ltnp | rg '127.0.0.1:242'

Investigation thread ID (if useful):

019cd8be-0c1e-7230-966b-4f7895dbb796

What is the expected behavior?

Even if separate MCP stacks for currently active subagents are intentional, the lifecycle should stay bounded and deterministic.

What I would expect:

• once subagents finish and are closed, their associated stdio MCP stacks should be torn down promptly, or
• the root Codex process should converge back to a small bounded baseline number of MCP children rather than monotonically accumulating more launcher processes over time.

In other words, repeated subagent waves should not leave a long-lived CLI session holding 7x, 10x, etc. copies of every configured stdio MCP launcher.

Additional information

Related issues I reviewed before filing this:

• #12333 - closed as not planned; maintainer said duplicate MCP instances while subagents are active can be by design
• #12976 - open; similar symptom, but the existing report is short and Windows-specific
• #11324 / #12491 - related memory/process pressure reports on the desktop app side

Why I am filing this separately anyway:

• this report is on the latest 0.112.0
• this is Linux CLI, not desktop-app-only
• I am providing current process-tree evidence across multiple stdio MCP types, not Serena alone
• the key claim is narrower than “please share one MCP across all agents”: the issue is unbounded growth / missing teardown under long-lived root CLI sessions

If useful, I can follow up with a cleaner minimal repro using a smaller MCP set and explicit spawn_agent / close_agent timing.