codex - 💡(How to fix) Fix Codex Desktop leaks MCP server processes from internal title-generation sessions on Windows [1 comments, 2 participants]

What version of the Codex App are you using?

Observed in Codex Desktop logs as app.version=0.125.0-alpha.3.

What platform is your computer?

Windows, PowerShell environment.

Related issues

Possibly related to #12491 and #18333, but this report has Windows-specific evidence and shows MCP stacks being launched for internal title-generation/helper sessions, not only normal visible task sessions.

What issue are you seeing?

Codex Desktop appears to start the full project MCP server set for internal helper/title-generation sessions and does not reliably reap those MCP subprocess trees after the helper/visible thread lifecycle ends.

This led to runaway MCP process pressure even when only two visible Codex sessions were open.

Evidence gathered

• MCP config was clean: no duplicate Codex MCP definitions and no missing expected MCP servers.
• Live process inventory showed repeated full six-server MCP launch clusters under one Codex app-server PID.
• Each cluster contained the configured project MCP servers: code_intel, context7, filesystem, lumen, playwright, and sem.
• Several launch times lined up exactly with Codex Desktop internal title-generation prompts, e.g. prompt text like Generate a concise UI title, rather than user-visible coding work.
• Archived/closed visible threads did not correspond to process cleanup; MCP roots remained after those threads were archived or inactive.
• On Windows, npx-based MCP servers also expand into wrapper/child trees (cmd.exe plus node.exe), and child node.exe server processes can remain after wrapper cleanup if the full tree is not reaped.

Expected behavior

Internal title-generation/helper sessions should not start the full project MCP stack unless they actually need MCP tools. If they do start MCP servers, those server process trees should be reaped when the helper session completes.

Actual behavior

The app-server accumulated stale MCP server process trees across internal/helper sessions. Visible chat count substantially underreported active MCP load, and new sessions/agent work became unreliable under the accumulated process pressure.

Impact

• Codex Desktop/agent startup can stall or become very slow.
• Host-wide MCP process pressure grows even when the visible number of sessions is small.
• Restarting/closing visible chats may not fully clean up orphaned or stale MCP server processes.

Local workaround

I added a repo-local health/cleanup workaround that detects logical MCP instances, distinguishes raw wrapper processes from logical server roots, attributes owners (Codex:<pid>, Claude:<pid>, Other/Detached), and can dry-run or reap stale recognized MCP process trees:

python .codex/skills/tool-health/scripts/mcp_health.py --cleanup-dry-run
python .codex/skills/tool-health/scripts/mcp_health.py --cleanup-stale-processes --fail-on-process-pressure

After manually reaping the stale MCP process trees, the local health check returned:

total_mcp_processes: 0
total_mcp_instances: 0
warnings: []

Suggested fix

• Avoid attaching the full project MCP stack to internal title-generation/helper sessions unless required.
• Ensure Codex Desktop reaps the entire MCP process tree, including npx wrapper descendants, when helper sessions or visible sessions end.
• Consider surfacing internal/helper MCP sessions in diagnostics so visible chat count does not hide process pressure.