›_ Codex Issues
Codex Issues / #19858

Codex Desktop leaks MCP server processes from internal title-generation sessions on Windows

Resolved 💬 2 comments Opened Apr 27, 2026 by StrategicMilk Closed Apr 27, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

etraut-openai contributor · 4 months ago

Thanks for reporting. This is a duplicate of several existing bug reports including #12491.

I have a PR that should fix this issue once it's reviewed and merged.

marcelosaltori · 1 month ago

This appears to have regressed or remained incomplete in Codex Desktop 26.715.10079.0, bundled CLI 0.145.0-alpha.30, despite the shutdown work in #19753.

Desktop logs showed internal description sessions with:

  • thread/fork
  • feature=thread_description
  • status=error
  • Failed to generate thread description
  • Timed out waiting for structured result

These internal/helper sessions correlated with new MCP process generations. Separately, after four visible tasks completed and became idle, their MCP process trees remained alive under the Desktop app-server.

At peak, the retained local helper trees contained 309 node.exe, cmd.exe, and powershell.exe processes consuming approximately 27.2 GB. Targeted manual reaping reduced this to approximately 2 GB without removing MCP integrations or archiving conversations.

The local mitigation is:

  • use Streamable HTTP for MCP servers that are already remotely hosted;
  • disable ambient suggestions;
  • avoid unsolicited subagent fan-out;
  • reap only recognized stale MCP process trees.

The app-side fix is still needed: internal title/description sessions should not initialize the full MCP stack, and every completed helper/session must explicitly close its MCP manager and terminate the complete Windows descendant tree.