›_ Codex Issues
Codex Issues / #19469

fix: stdio MCP child process leak causing unbounded memory growth

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

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

26.416.11627

What subscription do you have?

Plus

What platform is your computer?

Linux 6.19.10-300.fc44.x86_64 x86_64 unknown

What issue are you seeing?

Long-running Codex sessions using stdio MCP servers leak child processes.

Observed behavior:

stdio MCP servers are repeatedly spawned during normal usage
previous MCP child processes are not cleaned up
process count continuously increases over time
no automatic cleanup occurs
restarting/killing Codex reaps the processes

This behavior is consistent with previously reported MCP lifecycle leaks in Codex (CLI, Desktop, and extensions), where stdio MCP processes accumulate instead of being reaped.

What steps can reproduce the bug?

Configure one or more stdio MCP servers (e.g. Playwright, Git MCP, etc.)
Start Codex Desktop
Open and switch between chats repeatedly
Monitor process count:
watch -n 2 -t 'date +"%T"; pgrep -fc "mcp|playwright|chrome-devtools|codex"'
Observe:
process count increases continuously
no decrease occurs over time

What is the expected behavior?

stdio MCP child processes should be cleaned up after session/tool lifecycle ends
process count should remain bounded
memory usage should remain stable

Actual behavior
MCP child processes accumulate indefinitely
process count increases with continued usage
no cleanup occurs until Codex is terminated

Additional information

Evidence
Process tree shows multiple duplicated MCP server processes under the same Codex app-server
Repeated instances of:
@playwright/mcp
git-mcp-server
shadcn mcp
context7 MCP
next-devtools MCP
Video evidence attached:
Shows real-time process count increasing while opening chats
Timestamp included
Sensitive content redacted

This appears related to existing MCP lifecycle issues where processes are spawned but not reaped
Behavior matches prior reports of unbounded MCP process growth and memory usage
Known issue affecting codex-cli 0.120.0 and related builds ()
Code credit:
commit 498aac674cc2bf29f12185b1344e89b006f4a64d (@RedesignedRobot)
Co-authored with @codex

https://github.com/user-attachments/assets/956fb226-9bad-4414-8027-e9b3fd60827a

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17832
  • #18881
  • #18333
  • #18965
  • #19338

Powered by Codex Action

luohoa97 · 4 months ago

This is not a duplicate, this is a dedicated issue for the patch

Attys-syttA · 4 months ago

I can confirm a very similar pattern on Windows with the VS Code Codex extension/app-server.

Environment:

  • Windows 11
  • VS Code Codex extension
  • Active host process: codex.exe app-server
  • stdio MCP servers configured: Serena, @modelcontextprotocol/server-filesystem, xcodebuildmcp

Observed behavior:

  • Multiple stdio MCP roots appeared under the same active codex.exe app-server.
  • In one session, Serena, filesystem MCP, and xcodebuildmcp each reached 2-3 parallel root processes.
  • While manually stopping the newest Serena branch, one extra filesystem MCP root and one extra xcodebuildmcp root also appeared.
  • Cleanup only stabilized after stopping full descendant branches, not just the leaf process.

Example process roots under the same codex.exe app-server:

  • Serena: uvx.exe 25344, uvx.exe 25788, later uvx.exe 28980
  • filesystem MCP: cmd.exe 24664, cmd.exe 25724, cmd.exe 28972
  • xcodebuildmcp: cmd.exe 24868, cmd.exe 25756, cmd.exe 28964

After explicitly stopping the younger full process branches, the state returned to one root per stdio MCP:

  • Serena: uvx.exe 25344
  • filesystem MCP: cmd.exe 24664
  • xcodebuildmcp: cmd.exe 24868

This matches the issue description: stdio MCP child processes appear to accumulate under the app-server lifecycle instead of being consistently reaped. The local workaround was full-branch cleanup plus re-check, but the durable fix likely belongs in the Codex app-server / stdio MCP lifecycle handling.

luohoa97 · 4 months ago

If any developers are seeing this, please build this new change and test if it fixes it. My platform isn't supported. Thanks.

helen010969-sys · 29 days ago

Windows reproduction with @lottiefiles/creator-mcp 0.1.3

I reproduced a closely related stdio MCP lifecycle failure in Codex Desktop on Windows.

Environment:

  • Windows 11 Home 10.0.26200 build 26200
  • Codex Desktop package 26.721.4979.0
  • Node.js v24.15.0
  • npm 11.12.1
  • @lottiefiles/creator-mcp 0.1.3

Reproduction:

  1. Configure the MCP server with:

npx -y @lottiefiles/creator-mcp@latest

  1. Open LottieFiles Creator in the browser and enable MCP.
  2. In one Codex Desktop task, call get_rules, then get_api_doc pages 1–4, then run_script.
  3. Inspect the codex app-server child process tree after the calls.

Observed:

  • Separate tool calls left multiple npx -> creator-mcp process chains owned by the Codex app-server.
  • Before run_script, 12 creator-mcp-related node processes were present.
  • run_script failed with the bridge reported unavailable.
  • Running all required calls sequentially inside one orchestration call instead ended with "Transport closed" before the write.
  • No Creator scene or draft was created.
  • Killing only the exact creator-mcp process chains returned the count to zero.

Expected:

  • One Codex session should reuse one stdio MCP process/transport for all tools from the same server.
  • get_rules, get_api_doc and run_script should use the same live transport.
  • Child processes should be reaped after the tool/session lifecycle ends.

This looks related to the existing stdio MCP process lifecycle defect, but adds a native Windows reproduction where duplicated server chains also prevent a stateful browser-bridge MCP from completing a write operation.