Subagents leak stdio MCP helper trees in Codex App; xcodebuildmcp and chrome-devtools-mcp accumulate indefinitely

[jaewon-kim-dev]

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

26.409.20454 (build 1462)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Codex App appears to leak stdio MCP helper process trees when subagents are spawned.

On my machine, every time Codex creates a subagent / thread spawn, it appears to initialize MCP again for the subagent session, including:

• npm exec xcodebuildmcp@latest mcp
• npm exec chrome-devtools-mcp@latest --isolated --no-usage-statistics --no-performance-crux

Those helpers are not being cleaned up reliably after the subagent/session closes. Over time they accumulate and drive memory pressure and swap usage extremely high.

Current process state I captured while Codex App was still running:

• Codex app-server PID: 67522
• stale/accumulated npm exec ... parents: 394
• node ... xcodebuildmcp mcp children: 198
• chrome-devtools-mcp children: 199
• total related processes: 791
• combined RSS of those related processes: about 13.5 GB

Breakdown:

• npm exec ... parents: about 6.9 GB RSS
• xcodebuildmcp children: about 3.2 GB RSS
• chrome-devtools-mcp children: about 3.4 GB RSS

This is large enough that macOS starts consuming tens of GB of swap.

The pattern I see in logs is:

• spawn_agent
• thread_spawn
• session_init.mcp_manager_init
• Codex session closes almost immediately
• but the spawned MCP helper processes remain alive for tens of minutes or longer

So the issue looks like a lifecycle / teardown bug in Codex App rather than a bug inside xcodebuildmcp itself.

What steps can reproduce the bug?

I do not yet have a minimal deterministic repro, but this reproduces repeatedly during normal use in Codex App.

My environment includes:

• Codex App on macOS
• build-ios-apps plugin enabled
• global chrome-devtools MCP enabled
• frequent use of subagents / spawn_agent

Rough repro pattern:

1. Start Codex App.
2. Work in a thread that uses subagents repeatedly.
3. Have plugins / MCP-backed tools available, especially:
   • xcodebuildmcp
   • chrome-devtools-mcp
4. Continue using the app for a while, spawning multiple subagents over time.
5. Inspect processes with ps / Activity Monitor.

Observed result:

• each subagent/thread spawn appears to trigger a fresh MCP manager init
• new npm exec ... MCP parents and helper children are spawned
• old helper trees are not cleaned up
• process count and memory usage keep growing

Relevant local observations:

• app-server parent PID was 67522
• I saw log sequences like:
  • spawn_agent
  • thread_spawn
  • session_init.mcp_manager_init
  • immediate codex: close
  • but corresponding xcodebuildmcp / chrome-devtools-mcp processes remained alive

This may be related to or a regression adjacent to earlier MCP leak issues, but I am still seeing it on:

• Codex App 26.409.20454
• Codex CLI/core version family corresponding to current 0.120.0

I can provide logs, process snapshots, or uploaded thread/session details if needed.

What is the expected behavior?

Codex App should not leave stdio MCP helper trees running after a subagent or spawned session is finished.

Expected behavior:

• MCP helper processes should be reused safely or torn down reliably
• ending a subagent/session should clean up its entire MCP subprocess tree
• repeated spawn_agent usage should not grow the number of xcodebuildmcp / chrome-devtools-mcp helpers without bound
• long-running Codex App usage should not consume tens of GB of swap because of stale MCP helpers

Additional information

Related symptoms seem close to issues #16895, #14950, and #17448, but I am reporting a current Codex App repro with concrete process counts and memory usage.

[github-actions]

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

• Stdio MCP child processes are not cleaned up and accumulate indefinitely #16895
• Codex Desktop leaks stale local MCP wrapper processes after session shutdown #17115
• MCP sub-agent processes are never terminated when codex sessions are stopped/suspended #16256
• app-server websocket disconnect leaves orphaned MCP-backed threads loaded #16660

Powered by Codex Action

[RedesignedRobot]

Same bug, different MCP server. We observed 213 leaked @playwright/mcp process pairs (13.6 GB RSS) on v0.120.0. Filed as #17832.

Your description of the spawn_agent -> thread_spawn -> session_init.mcp_manager_init -> close lifecycle is accurate. We traced it through the source: each Session::new() creates its own McpConnectionManager::new() with fresh child processes, but handlers::shutdown() never calls cleanup on MCP. McpConnectionManager has no Drop impl, no shutdown(), no close().

Root cause analysis with proposed fix: #17832 (comment)
#17832 (comment)