codex - 💡(How to fix) Fix Regression: Playwright MCP stdio processes still leak after #16895 fix — 213 orphaned pairs, 13.6 GB RSS [3 comments, 2 participants]

Regression: Playwright MCP stdio processes still leak after #16895 fix — 213 orphaned pairs, 13.6 GB RSS

Environment

Summary

Issue #16895 (stdio MCP child processes not cleaned up) was closed on April 9 as fixed. As of April 14 on codex-cli 0.120.0, the bug is still present — specifically for @playwright/mcp configured as a global stdio MCP server in config.toml.

After a normal day of use in Codex Desktop involving multi-agent / subagent workflows, 213 leaked npm exec @playwright/mcp@latest + node playwright-mcp process pairs accumulated under the codex app-server process tree, consuming 13.6 GB of RSS and contributing to Activity Monitor reporting ~24 GB total for Codex.

This is the same root cause as #17574 (xcodebuild/chrome-devtools MCP leak) and #12491 (original 37 GB / 1300+ zombie report). The lifecycle fix from #16895 did not fully resolve the problem — subagent thread teardown still does not reap MCP child processes.

Forensic data

Process tree before cleanup

codex app-server (PID 4938, 993.8 MB physical footprint)
├── 213 × npm exec @playwright/mcp@latest  (~35 MB each = 7.4 GB)
│   └── each spawns: node playwright-mcp   (~30 MB each = 6.2 GB)
└── (total leaked MCP processes: 426, total leaked RSS: 13.6 GB)

Memory breakdown (physical footprint via vmmap)

app-server malloc analysis (PID 4938)

DefaultMallocZone: 179.3 MB resident + 792.5 MB swapped
                   5,023,995 allocations, 880.6 MB allocated
                   335.8 MB stack across 61 threads

The app-server itself has ~5M live allocations and 792 MB swapped out — likely holding session state / MCP connection metadata for all 213 leaked connections.

Reproduction context

• config.toml has @playwright/mcp@latest as a global stdio MCP server
• Normal usage pattern: Codex Desktop with multi-agent workflows (max_threads = 20, max_depth = 2)
• 927 total threads in state_5.sqlite, 476 spawn edges
• Heavy subagent use: one parent thread spawned 58 children, another 37
• Each subagent session appears to spawn → session_init → mcp_manager_init → spawn new MCP processes
• When the subagent session closes, the MCP processes are not terminated

Log evidence from logs_2.sqlite

The codex_core::spawn and codex_mcp::mcp_connection_manager modules show the pattern:

1. thread_spawn creates a new subagent session
2. session_init → mcp_manager_init starts fresh MCP connections (including Playwright)
3. Session completes and thread is marked closed in thread_spawn_edges (status = "open" — note: even completed edges show status "open", suggesting the edge status itself may not be updated)
4. The spawned npm exec @playwright/mcp@latest and its node playwright-mcp child remain alive indefinitely

Immediate workaround

pkill -f "playwright-mcp"
pkill -f "npm exec @playwright/mcp"

This instantly freed ~13.6 GB. Playwright MCP respawns correctly for the next thread that needs it.

Expected behavior

• MCP child processes should be terminated when their owning thread/session closes
• Subagent sessions should either share the parent's MCP connections or reliably clean up their own
• The codex app-server should not accumulate unbounded child processes over the course of normal use

Related issues

• #16895 — closed as fixed April 9, but the bug persists (this report)
• #17574 — same leak pattern with xcodebuildmcp and chrome-devtools-mcp (open)
• #12491 — original report: 1300+ zombies, 37 GB leak (open)
• #12333 — duplicate Serena MCP instances from multi-agent spawns (closed)