Repository navigation
Regression: Playwright MCP stdio processes still leak after #16895 fix — 213 orphaned pairs, 13.6 GB RSS #17832
Description
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.tomlhas@playwright/mcp@latestas 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:
thread_spawncreates a new subagent sessionsession_init→mcp_manager_initstarts fresh MCP connections (including Playwright)- 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) - The spawned
npm exec @playwright/mcp@latestand itsnode playwright-mcpchild 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-servershould not accumulate unbounded child processes over the course of normal use
Related issues
- Stdio MCP child processes are not cleaned up and accumulate indefinitely #16895 — closed as fixed April 9, but the bug persists (this report)
- Subagents leak stdio MCP helper trees in Codex App; xcodebuildmcp and chrome-devtools-mcp accumulate indefinitely #17574 — same leak pattern with
xcodebuildmcpandchrome-devtools-mcp(open) - Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491 — original report: 1300+ zombies, 37 GB leak (open)
- Codex CLI multi-agent spawns duplicate Serena MCP instances instead of sharing one connection #12333 — duplicate Serena MCP instances from multi-agent spawns (closed)
Activity
github-actions commentedon Apr 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
RedesignedRobot commentedon Apr 14, 2026
Root Cause Analysis
Verified across 4 independent passes of the
codex-rs/source onmain.Summary
McpConnectionManagerhas no cleanup mechanism.handlers::shutdown()terminates shell processes but never touches MCP. Child processes accumulate because nothing initiates the drop chain toProcessGroupGuard.The drop chain that should fire but does not
ProcessGroupGuard::drop()atrmcp_client.rs:385works correctly. It is never invoked.Verified gaps
1.
handlers::shutdown()ignores MCP —codex.rsL5814Calls
unified_exec_manager.terminate_all_processes()for shell processes. Zero references tomcp_connection_manager.2.
McpConnectionManagerhas no cleanup code —mcp_connection_manager.rs, 1824 linesNo
Dropimpl. Noshutdown(). Noclose(). Noterminate(). Theclients: HashMap<String, AsyncManagedClient>holdingArc<RmcpClient>references is never cleared.3.
shutdown_live_agent()does not force MCP teardown —agent/control.rsSends
Op::Shutdown, callsremove_thread()(decrements Arc refcount), callsrelease_spawned_thread(). Does not touch MCP. If any reference to the Session survives, the drop chain stalls.4. CancellationToken is startup-only —
mcp_connection_manager.rsWraps
start_server_task().or_cancel(&cancel_token). Only cancels in-progress connection attempts. Inert once a client reachesClientState::Ready.5. Each subagent creates its own MCP connections —
codex.rs,Session::new()Each
Session::new()callsMcpConnectionManager::new(), spawning fresh child processes per subagent. Per-session scoping is correct. Per-session cleanup does not exist.PR #17223 was incomplete
Changed 3 files in
codex-rs/app-server/. Fixedconnection_closed()incodex_message_processor.rs— handles WebSocket client disconnect. Does not address subagent internal teardown. Subagents do not go through the WebSocket disconnect path.Log evidence
From
logs_2.sqliteon this machine:thread_spawn_edgesstill status "open": 315Fix (as shipped on branch)
The original draft used an async
shutdown().awaitwith explicitmanaged.client.close().awaitper client. The syncclients.clear()variant is equivalent: droppingAsyncManagedClientreleases theArc<RmcpClient>, which dropsProcessGroupGuardand triggersterminate_process_group. Fewer moving parts, no await needed.Files
codex-rs/core/src/codex.rsL5814handlers::shutdown()missing MCP cleanupcodex-rs/codex-mcp/src/mcp_connection_manager.rscodex-rs/core/src/agent/control.rsshutdown_live_agent()does not trigger MCP teardowncodex-rs/rmcp-client/src/rmcp_client.rsL385ProcessGroupGuard::drop()works but is never reachedRedesignedRobot commentedon Apr 14, 2026
Reference implementation: main...RedesignedRobot:codex:fix/mcp-subprocess-cleanup
2 files, +23/-2. Covers both
handlers::shutdown()(Op::Shutdown path) and thesubmission_loopchannel-close fallthrough.cargo check -p codex-core -p codex-mcpclean.Verified across 7 independent code review passes covering Drop semantics, call ordering, concurrency safety, and termination path coverage. Covers all primary termination paths. No deadlock risk in the Drop chain.
fortunexbt commentedon Apr 15, 2026
@RedesignedRobot this is the worst MCP lifecycle failure I have seen documented — 426 orphaned process pairs from 927 threads because subagent teardown never reaps MCP children. The forensic detail is excellent.
The operators I talk to hit this most often in unattended multi-agent runs where the process leak accumulates over hours until the host OOMs. The root cause you traced — no
McpConnectionManager.shutdown()inhandlers::shutdown()— explains why PR #17223 only fixed the WebSocket disconnect path while subagents kept leaking.Is the bigger gap for you right now per-agent process isolation so leaks stay bounded, or runtime visibility that surfaces which subagents leaked their MCP processes before the host runs out of memory?
RedesignedRobot commentedon Apr 15, 2026
The immediate gap is the missing teardown call.
handlers::shutdown()never invokes cleanup onMcpConnectionManager. The reference implementation linked above addresses this directly. Once the drop chain fires correctly, the leak stops at source.Process isolation is a secondary concern. Each subagent already gets its own
McpConnectionManagerviaSession::new(), so the scoping is correct. The problem is purely that the cleanup path was never wired. Bounding leaks per-agent would be defense-in-depth, not a fix for the root cause.Runtime observability would be the more useful follow-up. A process count metric emitted per-session at teardown (or periodically by the app-server) would catch regressions and make leaks visible before they reach OOM. The structured logging infrastructure is already there (
logs_2.sqlite,codex_mcp::mcp_connection_managertarget). It just needs a counter for active stdio child processes.For unattended multi-agent runs specifically, a lightweight reaper in the app-server that periodically reconciles live MCP child PIDs against active
thread_spawn_edgeswould catch any edge cases the explicit teardown misses (forced SIGTERM, caller timeouts, Arc reference leaks).2 remaining items
RedesignedRobot commentedon Apr 19, 2026
Hey @jif-oai @etraut-openai, dropping a note in case it's useful.
Patch is ready on
RedesignedRobot:codex:fix/mcp-subprocess-cleanup, rebased onmain.Fix: adds
McpConnectionManager::shutdown()(drains the client map) and calls it fromhandlers::shutdown()alongside the existing shell teardown. Dropping theArc<RmcpClient>refs letsProcessGroupGuard::drop()fire and SIGTERM the MCP child process groups. This is the subagent shutdown path #17223 didn't cover.Also covers the
submission_loopchannel-close fallthrough, which previously drained only guardian state and leaked the same processes on abnormal channel closure.2 files, +23/-2, no behavior change on the happy path.
cargo check -p codex-core -p codex-mcpclean.Happy to open as a PR if you can invite me in.
Thanks.
fix: terminate MCP child processes on session shutdown
gregoramon commentedon Apr 28, 2026
Additional data point: Codex.app desktop, version 0.125.0-alpha.3
Confirms the regression persists in the current alpha.
Environment
codex-cli 0.125.0-alpha.3(Codex.app desktop)@playwright/mcp@latestObserved pattern
Six orphaned
npm exec @playwright/mcp@latestprocesses, all withPPID = Codex app-server (PID 46443). They spawn in pairs ~1–2 minutes apart, on three distinct occasions over the 33h Codex.app uptime:Matches the root cause @RedesignedRobot traced:
McpConnectionManagerwas replaced (3× here, presumably on session/reconnect) without draining itsclientsmap, so theArc<RmcpClient>refs that should triggerProcessGroupGuard::drop()are never released. Codex.app itself never exited, so no shutdown path fires.The 31h-old pair had spawned `chrome-headless-shell` children running 1d 3h, two of them holding 13.3% / 8.3% CPU steady.
Resource impact
On a 64 GB machine, after 33h of Codex.app uptime:
`kill ` on the stale orchestrators terminated cleanly — they were orphaned, not stuck.
etraut-openai commentedon Apr 28, 2026
I have a pending PR that should address this. If you're so inclined, you could try building the PR from source and confirm that it does address the problem you're seeing.
nazordz commentedon May 7, 2026
Additional data point: still reproducible with
@mui/mcpon macOS after the MCP shutdown fix.Environment
0.128.0@mui/mcp@latestconfigured globally via stdio/npxConfig:
Observed
After repeated Codex sessions, I found:
npm exec @mui/mcp@latestparent processesnode .../.npm/_npx/.../node_modules/.bin/mcpchild processesnpm exec @mui/mcp@latestparents hadPPID 1, adopted bylaunchd767 MBExample stale process group:
Current live Codex session creates a fresh group:
Permission check
The stale processes are owned by my user. A harmless signal permission check succeeds outside Codex's restricted context:
Both return success.
Codex log evidence
Codex logs contain repeated MCP cleanup failures:
Interpretation
This looks like the stdio MCP cleanup leak still reproducing with
@mui/mcp@lateston Codex0.128.0. The processes are same-user and signalable from the host, but Codex cleanup appears to fail from its sandbox/restricted context, leaving MCP process groups orphaned underlaunchd.mySebbe commentedon May 12, 2026
Additional Windows process-growth data point from Codex Desktop
26.506.3741.0.This is not
@playwright/mcpspecifically, but it looks like the same class of browser automation lifecycle problem: long-lived Chrome/Playwright controlled browser profiles are not returning to a bounded baseline.Observed live process footprint:
The largest group is the fallback/controlled Chrome profile, not the
node_repl.exeMCP hosts. A local conservative cleanup is now managing stalenode_repl.exe, but browser fallback Chrome processes remain the dominant footprint.Cross-links where the routing/fallback side is discussed: #21868, #19365, #20417.
waypointmini-rgb commentedon May 31, 2026
Independent reproduction — same lifecycle bug still present on a much later Codex App build, with a different MCP server set, so this is not specific to
@playwright/mcpor to thechrome-devtools-mcp/xcodebuildmcppair in #17574.Environment
26.527.30818(build 3370)codex-cli 0.135.0-alpha.1com.openai.codexobsidian-mcp,notebooklm-mcp,@playwright/mcp@latest(stdio),SkyComputerUseClient mcpForensic data — single live Codex App session, ~19h uptime
Single live
codex app-server --analytics-default-enabledparent (PID 49055, age 19h14m) owns the entire leaked tree. Parent is alive and healthy; children are not orphans.This is the exact pattern from #17574 — every subagent / computer-use session refresh runs
session_init.mcp_manager_init, spawns a fresh MCP quartet, and the previous quartet is never reaped even though the new session is now wired to its own helpers. Ratio is roughly 1 quartet per session refresh; with computer-use refreshing about hourly, that's ~20 quartets accumulated in this window. Matches the per-session-init growth rate in #17574 exactly.Why this is not the SDK-side stdin-EOF leak
A common confusion: the typescript-sdk side has a related leak class fixed by modelcontextprotocol/typescript-sdk#2003 —
StdioServerTransportnot exiting on stdin close. That fix only helps when the MCP server's parent has actually died and stdin EOF has been delivered.Here the Codex App
app-serverparent is still alive and (I assume) still holding the stdio pipes open for each abandoned child. From the child's perspective stdin is not closed, so no SDK-side stdin-EOF /closelistener can save us. The teardown receipt has to come from the app-server side — either explicit kill of the prior session's child set on session-init, or closing the pipes so the SDK-side EOF handler can take over.Suggested triage
26.527.30818, so Stdio MCP child processes are not cleaned up and accumulate indefinitely #16895's fix isn't a full cure even in versions much later than the one in Regression: Playwright MCP stdio processes still leak after #16895 fix — 213 orphaned pairs, 13.6 GB RSS #17832.session_init.mcp_manager_init— not relying on parent-process death to cascade cleanup.codex app-server's child set and TERMs the staler quartets does work as a local mitigation, but is upstream-of-real-fix.Happy to share further
lsof/ps -axo pid,ppid,etime,commandcaptures or a longer time series if it would help reproduce on the maintainer side.nukk-pain commentedon Jul 14, 2026
Adding a current non-Playwright reproduction of the same subagent stdio MCP teardown failure.
Environment
0.144.3256Observed
Across local session JSONL logs, I found 54 distinct tool-call failures with:
The failures affected 11 session logs over about 67 minutes. Once degraded, even
pwdandgit status --shortcould not start.For one long-running root Codex process:
spawn_agentcalls in the root session logThe direct child count tracks the accumulated subagent MCP stacks rather than only currently running agents. Completed subagents therefore leave stdio MCP processes/pipes attached to the long-lived root until it approaches the 256 FD limit.
Expected
Subagent completion should tear down its stdio MCP stack, or the parent should converge to a bounded baseline. A completed subagent should not leave enough pipes behind to prevent unrelated local commands from spawning.
Local mitigation
I reduced
max_concurrent_threads_per_sessionfrom 1000 to 16. This limits impact but does not fix teardown. No private logs or repository data are attached.Turnstyle commentedon Jul 17, 2026
I am seeing the same MCP lifecycle leak with:
26.707.91948(build5440)0.144.526.5.2(build25F84)After completed subagent work, approximately 170 MCP-related processes remained alive. Their summed RSS was approximately 16.5 GiB. I understand summed RSS is an upper bound because shared pages may be counted repeatedly; nevertheless, MCP process counts and memory use increase with repeated subagent fan-out and do not return to the pre-fan-out baseline.
Observed sequence:
Expected behavior: when a subagent completes or is closed, Codex should close its MCP stdin connections and terminate its owned MCP process group, or safely reuse a bounded shared connection pool.
I can provide sanitized before/after measurements and process-tree evidence if useful. I will exclude credentials, environment variables, private filesystem paths, and proprietary repository information.
EthanSK commentedon Jul 18, 2026
Current-build corroboration: Desktop 26.715.31925 / CLI 0.145.0-alpha.18
This remains reproducible on a newer unified ChatGPT/Codex macOS build. This snapshot was gathered read-only; I did not terminate helpers, edit SQLite state, change configuration, or restart the app.
Environment
26.715.31925(build5551)0.145.0-alpha.1825F84),Darwin 25.5.0 arm64 arm@playwright/mcp@latestnx mcpnode_replLive process and memory evidence
A single persistent Desktop app-server owned repeated helper roots:
The direct roots alone summed to approximately:
Walking the complete descendant trees for these three helper families found 121 processes using approximately 3.63 GiB summed RSS. Summed RSS is an upper bound because shared pages can be counted more than once, but the process multiplier is unambiguous.
The persistent app-server itself was approximately 818 MiB RSS in the same investigation. macOS reported 8.18 GiB swap in use out of 9 GiB allocated. Current memory pressure had recovered to 61% free, so this was not a claim that the host was actively OOM at capture time.
The helper roots appeared in repeated timestamp-aligned clusters. Most clusters contained one Playwright launcher, one Nx launcher, and one Node REPL host, consistent with a fresh per-session MCP initialization rather than one shared project/runtime pool.
Local log evidence
The current
logs_2.sqlitecontains explicit task teardown events such as:Four such teardown sequences occurred between 19:35:08 and 19:37:09 local time. The helper clusters remained alive under the same app-server afterward.
The
rmcp::transport::child_processtarget had no matching child-exit records during the current app-server lifetime. Its most recent exit records were from the previous app-server lifetime and showed Playwright, Nx MCP, and Node REPL exiting around a prior resume/restart boundary. This is consistent with full app-server termination cleaning the tree while ordinary task/subagent shutdown does not.The logs also show the initialization path:
Persisted lifecycle evidence
The active
state_5.sqlite.thread_spawn_edgestable contained:The 164 open child rows were not archived. This independently supports the stale subagent lifecycle problem tracked in #33700.
Crash evidence boundary
I found historical Crashpad sidecars, including renderer and browser process types, but no matching renderer crash in the two-hour unified-log window used for this live memory snapshot. I am reporting the process/RAM lifecycle leak here, not claiming that this specific snapshot ended in a fresh crash.
Expected behavior
thread_spawn_edgesrows toclosed.PR #19753 was merged as a shutdown cleanup fix, but this later build still reproduces the leak on the task/subagent teardown and restore paths.
Related: #33700, #30408, #32942.
I have not attached raw logs, SQLite databases, session transcripts, environment variables, task IDs, prompts, repository names, or personal filesystem paths because those artifacts may contain private information. I can provide narrower sanitized queries or process snapshots if a maintainer needs them.
philkunz commentedon Jul 19, 2026
Independent sanitized Linux reproduction of the Playwright MCP lifecycle leak.
Environment
codex-cli 0.144.5codex app-server --listen unix://process, approximately 27 hours oldnpm exec @playwright/mcp@latestProcess evidence
npm exec @playwright/mcp@latestchildren.playwright-mcpNode descendant.playwright_chromiumdev_profile-*user-data directory. This confirms separate MCP generations do not share one browser by default, while many MCP launchers may never have launched a browser.SIGTERM; this is cross-reported in app-server: degraded broker catches SIGTERM then deadlocks on a futex (needs SIGKILL); healthy broker exits <1s #34142.SIGKILLbypassed normal cleanup.The direct-parent relationship, spread of process ages, and retained earlier generations match the missing per-session/subagent MCP teardown described in this issue. No project paths, hostnames, account data, configuration contents, browser profile identifiers, or session data are included.
fix(mcp): reap superseded MCP connection managers on refresh
CodeGlitch commentedon Aug 16, 2026
Confirmed on Windows x64 with Codex Desktop 26.810.7004.0 and global
@playwright/mcp@lateststdio configuration. After Playwright tasks had finished and no browser automation session was active, 372 Playwright-related processes remained. Terminating only those processes reclaimed about 12.18 GB. The process trees later began accumulating again. No session transcript or private project data is included.