fix: stdio MCP child process leak causing unbounded memory growth

[luohoa97]

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 498aac6 (@RedesignedRobot)
Co-authored with @codex

bug.mp4

[github-actions]

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

• Regression: Playwright MCP stdio processes still leak after #16895 fix — 213 orphaned pairs, 13.6 GB RSS #17832
• MCP child processes leak when McpConnectionManager is replaced #18881
• Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure #18333
• VS Code extension leaks and duplicates local stdio MCP processes on Windows #18965
• VS Code extension starts the same MCP stdio server twice from one config entry #19338

Powered by Codex Action

[luohoa97]

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

[Attys-syttA]

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]

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