Stale MCP "node" helper process trees from older sessions

[kaleidoKurt]

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

26.313.41514 Codex build: 1043

What subscription do you have?

Pro

What platform is your computer?

macOS: 26.3.1 (25D2128) - Hardware: Apple M2 Max - RAM: 64 GB

What issue are you seeing?

Codex appears to leave behind stale MCP helper process trees from older sessions. Over time these accumulate and cause large CPU/RAM spikes.

The recurring offenders on my machine are mostly:

• node ... xcodebuildmcp mcp
• node ... apple-docs-mcp
• orphaned npm exec ... parents for those helpers

I have seen this happen repeatedly across multiple days. The stale processes are not descendants of the current live Codex app session.

I also observed the same pattern on an earlier Codex version:

• Codex version seen on earlier incidents: 26.305.950

Actual behavior

After using Codex with MCP-backed tooling and then closing/restarting/abandoning sessions, old helper trees remain running in the background.

Over time this leads to many node processes consuming large amounts of RAM and CPU.

What steps can reproduce the bug?

I do not have a minimal deterministic repro yet, but the issue happens repeatedly after normal Codex use with MCP-backed tools over multiple sessions/days.

My rough repro pattern is:

1. Use Codex with MCP-backed tools, especially Xcode-related flows.
2. Close Codex, restart it, or leave/abandon sessions.
3. Repeat over time.
4. Observe many lingering node helpers from older sessions.
5. Activity Monitor shows a large number of node processes and high RAM/CPU usage.

Examples I captured:

March 10, 2026

• 28 stale xcodebuildmcp helpers
• about 12.4 GB RAM used by those stale helpers

March 11, 2026

• 49 stale xcodebuildmcp helpers
• about 15.45 GB RAM
• 100 stale apple-docs-mcp helpers
• about 1.44 GB RAM

March 17, 2026

• 26 stale xcodebuildmcp helpers
• about 11.69 GB RAM
• 66 stale apple-docs-mcp helpers
• about 2.72 GB RAM

On March 17, system free memory was around 32% before cleanup and returned to 86% after killing only the stale Codex helper trees.

What is the expected behavior?

Expected behavior

When Codex closes, crashes, or abandons a session, its MCP helper process trees should be cleaned up automatically.

At minimum:

• old MCP helper trees should not survive indefinitely
• a new Codex session should not leave old helper trees detached
• helpers should be tied to the current live Codex app/app-server lifecycle

Additional information

The stale processes were not part of the current live Codex process tree. I had to do tree-aware cleanup to avoid killing the current active Codex helpers.

This seems broader than only XcodeBuildMCP. I also saw the same stale-process pattern with apple-docs-mcp.

If useful, I can also provide:

• Activity Monitor screenshots
• sanitized ps output
• the cleanup script I used to identify stale helpers while preserving the current live Codex session

[github-actions]

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

• Codex spawning too many mcp instances and never kills them, memory is getting overwhelmed #14548
• Codex App: app-owned @playwright/mcp can leave Google Chrome Helper running until app restart #14773
• Codex CLI 0.112.0: long-lived multi-agent sessions accumulate duplicate stdio MCP stacks instead of returning to a bounded baseline #14233
• Desktop app recreates stdio MCP sessions whenever the window regains focus on Windows #13680
• High CPU from node processes #13196

Powered by Codex Action