›_ Codex Issues
Codex Issues / #16895

Stdio MCP child processes are not cleaned up and accumulate indefinitely

Resolved 💬 2 comments Opened Apr 6, 2026 by Dovlan1990 Closed Apr 9, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex appears to leak stdio-based MCP child processes over time, especially when using @playwright/mcp.

In long-lived sessions, resumed sessions, VS Code app-server sessions, or flows involving subagents, new MCP child processes keep getting spawned, but old ones are not terminated. Over time this leads to dozens or hundreds of stale processes and multiple GB of RAM usage.

This looks like a lifecycle / process-reaping bug in Codex rather than an issue in the MCP server itself.

What steps can reproduce the bug?

I cannot give a perfect deterministic reproduction yet, but this reproduces reliably over normal use:

  1. Configure a stdio MCP server such as @playwright/mcp
  2. Start Codex in CLI or via the VS Code extension
  3. Use MCP-backed tools repeatedly over time
  4. Resume sessions and/or use subagents
  5. Inspect processes with ps

What is the expected behavior?

  • MCP child processes should be reused where possible, or
  • terminated reliably when their owning session / subagent / app-server no longer needs them
  • idle MCP servers should not live forever
  • ending a session should clean up the entire MCP subprocess tree

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16256
  • #16144
  • #16660

Powered by Codex Action

RedesignedRobot · 4 months ago

This was closed prematurely. PR #17223 fixed the WebSocket client disconnect path (connection_closed() in codex_message_processor.rs). It did not address subagent session teardown.

We hit the same bug on April 14 running v0.120.0 (which includes the fix): 213 leaked @playwright/mcp process pairs, 13.6 GB RSS. Filed as #17832.

Root cause: McpConnectionManager has no cleanup code. handlers::shutdown() ignores MCP entirely. ProcessGroupGuard::drop() works but is never invoked because nothing initiates the drop chain.

Root cause analysis with source references and proposed fix: #17832 (comment)
https://github.com/openai/codex/issues/17832#issuecomment-4247026597