Skip to content

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

@RedesignedRobot

Description

@RedesignedRobot

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

Environment

Field Value
Codex CLI codex-cli 0.120.0
Codex App 26.409.20454
Subscription ChatGPT Pro
Platform macOS 26.4.1 (25E253), Apple M3 Pro, 36 GB RAM
MCP server @playwright/mcp@latest (stdio transport)

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)

Process PIDs Physical Footprint
Codex main (Electron) 4892 177.0 MB
codex app-server (Rust) 4938 993.8 MB
Renderer #1 4950 560.2 MB
Renderer #2 5676 134.5 MB
Renderer #3 5729 134.7 MB
GPU process 4895 514.6 MB
Network service 4897 16.3 MB
Tracing service 61658 51.3 MB
213 × npm exec playwright various 7,550 MB (7.4 GB)
213 × node playwright-mcp various 6,304 MB (6.2 GB)
Grand total 433 processes ~15.3 GB RSS

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 spawnsession_initmcp_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_initmcp_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

Metadata

Metadata

Assignees

No one assigned

    Labels

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

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions