›_ Codex Issues
Codex Issues / #12491

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak

Open 💬 38 comments Opened Feb 22, 2026 by rolldav
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak

What version of Codex CLI is running?

codex-cli 0.98.0 (Codex.app GUI wrapper)

What subscription do you have?

ChatGPT Pro

Which model were you using?

o3 (via Codex.app GUI)

What platform is your computer?

macOS 26.3 (25D125), Apple M4 Max, 64GB RAM, arm64

What issue are you seeing?

Codex.app spawns codex exec --full-auto worker processes for each worktree but never reaps them or their MCP child processes when tasks complete. Over multiple audit sessions, this accumulated 1,319 zombie Codex processes and 1,537 node processes consuming \~37GB RSS + 40GB swap on a 64GB machine, causing severe system-wide slowdown.

Root cause analysis

Each Codex.app task creates:

  • 1× codex exec --full-auto --skip-git-repo-check --json - (CLI worker)
  • 4× oh-my-codex MCP servers (state, memory, trace, code-intel)
  • 1× Serena MCP server (via uv tool uvx)
  • 1× uv process for Serena

≈ 7 processes per task. None are killed when the task completes.

With 12 git worktrees created by Codex.app (detached HEAD, pointing at old commits), this produced:

  • 12 worktrees × \~110 child processes = \~1,320 sleeping processes
  • Combined RSS: \~37GB (mostly npm/node/uv MCP servers)
  • Swap usage: 39.4GB (on 64GB physical RAM)

When Codex.app (PID 19947) was killed, 2 additional codex exec workers (launched Friday and Saturday) were reparented to launchd (PPID=1), confirming they were never properly cleaned up.

Process tree snapshot (before cleanup)

Codex.app (PID 19947, 279MB)
├── codex exec --full-auto (PID 19970, 123MB)
│   └── 880× node/npm/uv children (27GB total)
│       ├── npm (236MB each, ×2)
│       ├── npm (140MB each, ×4)
│       ├── uv (91MB each, ×2)
│       └── node (77MB each, ×dozens)
├── Codex Helper Renderer (PID 20018, 602MB)
└── Codex Helper (PID 19971, 101MB)

Orphaned (PPID=1, reparented from dead Codex.app sessions):
├── codex exec --full-auto (PID 59326, Fri 23:59)
│   ├── oh-my-codex/state-server.js
│   ├── oh-my-codex/memory-server.js
│   ├── oh-my-codex/trace-server.js
│   ├── oh-my-codex/code-intel-server.js
│   └── serena start-mcp-server
└── codex exec --full-auto (PID 59747, Sat 22:05)
    └── (same MCP stack)

Memory impact

<!-- linear:table-colwidths:200,200,200,200 -->
| Metric | Before cleanup | After cleanup | Delta |
| -- | -- | -- | -- |
| Swap used | 39.4 GB | 8.0 GB | -31 GB |
| Codex processes | 1,319 | 0 | -100% |
| Node processes | 1,537 | 17 | -99% |
| Free pages | 82K | 2.3M | ×28 |

Worktree state at time of discovery

All 12 worktrees were detached HEAD on old commits (2+ phases behind current main), confirming tasks had completed long ago:

/Users/drg/.codex/worktrees/0585/medical-ai  627d44e (detached HEAD)
/Users/drg/.codex/worktrees/0b7b/medical-ai  627d44e (detached HEAD)
/Users/drg/.codex/worktrees/2a60/medical-ai  4d53e7d (detached HEAD)
... (12 total, all on 2 old commits)

Current HEAD: 71aefff — none of the worktrees were anywhere near current.

What steps can reproduce the bug?

  1. Use Codex.app GUI to run multiple tasks on a git repository (especially with MCP servers configured via oh-my-codex)
  2. Let tasks complete normally
  3. Wait a few hours / run more tasks
  4. Check process count: ps aux | grep -c codex
  5. Check memory: ps aux | grep codex | awk '{sum+=$6} END {printf "%.0f MB\n", sum/1024}'

Accumulation is proportional to number of tasks × MCP servers configured.

What is the expected behavior?

When a Codex.app task completes:

  1. The codex exec worker process should be terminated
  2. All MCP child processes (oh-my-codex servers, Serena, uv) should be killed via process group signal
  3. The git worktree should be cleaned up if the task is done (or at minimum, child processes should not persist)

What is the actual behavior?

  • Worker processes and their entire MCP subtree remain alive indefinitely
  • No cleanup occurs on task completion, app quit, or even app crash (reparented to launchd)
  • Memory grows unboundedly with each task

Relationship to existing issues

  • CLI-494 (fixed, Oct 2025): start_kill() without wait() in exec.rs — same root cause pattern (missing process reaping), but fix only covered timeout/Ctrl+C in CLI, not GUI lifecycle
  • CLI-3017 (Jan 2026): CLI memory leak causing crashes
  • [#12414](<https://github.com/openai/codex/issues/12414>) (Feb 2026, open): Unbounded memory growth when idle on v0.104.0

This issue is distinct because it specifically affects Codex.app GUI and its interaction with MCP server child processes — the GUI spawns long-lived codex exec workers that themselves spawn MCP servers, creating a deeper process tree that the existing cleanup logic does not handle.

Suggested fix

  1. Process group kill: codex exec workers should use setsid() / process groups so all children (MCP servers) can be killed with a single killpg() on task completion
  2. Worktree lifecycle: Codex.app should track active worktrees and clean up stale ones on startup (e.g., remove worktrees whose tasks are no longer active)
  3. Heartbeat/watchdog: MCP servers spawned by codex exec should monitor their parent and self-terminate if the parent dies (check PPID periodically, or use a pipe/fd that breaks on parent death)

View original on GitHub ↗

38 Comments

github-actions[bot] contributor · 6 months ago

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

  • #11324
  • #12335
  • #12333
  • #11090

Powered by Codex Action

vincentkoc contributor · 6 months ago

I put up a draft fix for this path: https://github.com/openai/codex/pull/12505

Scope is intentionally narrow and low-risk:

  • adds features.thread_listener_cleanup as an experimental flag (default off)
  • clears per-thread listener state when subscriber count drops to zero (when flag is enabled)
  • always clears app-server thread state during archive teardown
  • avoids event serialization work when there are no subscribers

I am currently seeing memory pressure in app usage with 5+ concurrent threads, so this is aimed at reducing retained in-memory thread/listener state without changing default behavior.

vincentkoc contributor · 6 months ago

Given the updated contribution policy (invitation-only PRs), #12505 is currently a draft patch proposal to make discussion concrete. If this direction aligns with maintainer intent, would someone from the team be willing to explicitly invite that PR (or suggest a narrower scope)? I can provide additional repro/profiling details from macOS sessions where memory pressure climbs with 5+ concurrent threads.

gabrielbryk · 5 months ago

Experiencing this on Linux / codex-cli 0.106.0

Reproducing the same issue. Here's a breakdown of the two distinct leak patterns I'm seeing:

Environment:

  • codex-cli 0.106.0
  • Ubuntu 25.10, Linux 6.17.0-14-generic x86_64

Crash: failed to spawn thread: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

Two distinct leak patterns observed:

  1. Zombie children not reaped (missing waitpid): A single long-running codex session accumulated 41 zombie <defunct> children — all from a Python stdio MCP server. The MCP server forks subprocesses for tool calls, but the codex parent never calls waitpid() to reap them. pstree output:

``
codex,49983
|-(MainThread,105811) <defunct>
|-(MainThread,125138) <defunct>
|-(MainThread,131433) <defunct>
... (41 total zombies)
``

  1. MCP server processes not terminated on session exit: When a codex session ends or is interrupted, its stdio MCP child processes are never sent SIGTERM. They persist indefinitely. I found 8 separate MCP process trees (one per stale codex session), each still running. These are live processes consuming real resources, not just zombies.

The combination of both leaks led to thread exhaustion and the crash. This appears to be the same root cause as #4726 (closed) and #6201 (closed) — neither of which fully resolved the lifecycle management for stdio MCP servers.

masvelio · 5 months ago

I can confirm a very similar issue on macOS, and I captured a full CLI process snapshot on March 11, 2026.

Environment

  • Codex App version: 26.305.950
  • macOS: 14.3.1 (23D60)
  • Usage pattern: multiple Codex App projects/threads open over time
  • MCPs in use: context7, stripe, playwright

What I observed

  • The machine was not in a peak CPU spike at the exact time of capture, but memory pressure was already high:
  • 607 total processes
  • 5760 threads
  • 15G used, 74M unused
  • 6608M compressor
  • 6342612 swapins
  • 8519545 swapouts
  • The most important part is the process tree under a single Codex desktop app-server PID:
  • codex app-server PID 60306
  • direct children of PID 60306: 73
  • of those, 72 were MCP launchers
  • exact breakdown:
  • 24 x npm exec @upstash/context7-mcp
  • 24 x npm exec @stripe/mcp --tools=all
  • 24 x npm exec @playwright/mcp@latest
  • including descendants, that subtree contained 148 processes total

This does not look like a bounded “currently active work only” baseline. It looks like repeated MCP launcher accumulation over time under the same long-lived codex app-server.

Long-lived duplicated MCP launcher examples

  • about 8h old:
  • npm exec @playwright/mcp@latest
  • npm exec @stripe/mcp --tools=all
  • npm exec @upstash/context7-mcp
  • about 4h old:
  • another full trio of playwright / stripe / context7
  • about 3h old:
  • more repeated trios
  • about 1h old:
  • more repeated trios
  • about 50m old:
  • more repeated trios
  • about 20h+ old:
  • more repeated trios still attached to the same app-server

Important distinction

  • I understand from #12333 that duplicate MCP instances may be expected while subagents/threads are active.
  • What seems wrong here is lifecycle / teardown:
  • the desktop app is not converging back to a small stable baseline
  • stale MCP launchers keep accumulating under the same codex app-server PID over many hours

This feels closely related to:

  • #12491
  • #11324
  • #12976
  • possibly the earlier stdio MCP cleanup work in #10710

Question for maintainers

  • Should the process-group cleanup merged in #10710 have covered this desktop app path as well?
  • Or is there still a separate cleanup gap in the desktop app / app-server lifecycle?

Thanks for taking a look. The snapshot seems to point to unbounded MCP process accumulation over time rather than short-lived fanout from currently active work, so hopefully it helps narrow the cleanup path.

RemarkRemedy · 5 months ago

This looks related to #11324, but I wanted to add a narrower app-server angle that may help isolate root cause.

I traced a reproducible case where the leaking MCP children are not orphaned from dead workers; instead they remain attached to the long-lived desktop codex app-server process after conversations are no longer active.

The key detail from source review is that MCP servers are conversation-scoped and the intended unload path is thread/unsubscribe. When the last subscriber unsubscribes, the app-server shuts down the thread and unloads it. However, on connection removal the current app-server code path retains zero-subscriber threads instead of unloading them, so their McpConnectionManagers never drop and the stdio MCP child processes stay alive.

I posted the fuller write-up and evidence here:

So this may be the same family of leak as this issue, but specifically through desktop thread lifecycle / unload behavior rather than only worker reaping.

dorukardahan · 5 months ago

Same bug family on my Mac

@masvelio and @gabrielbryk this looks very close to what I hit. @RemarkRemedy also makes sense to me here, but i think there is one more phase after that app-server retention phase.

My setup

  • Codex.app 26.311.21342 (build 993) when this built up
  • macOS Darwin 25.3.0 on Apple Silicon
  • app was open about 2.5 days
  • about 18 separate conversations/tasks in that window
  • MCPs involved: context7, playwright, chrome-devtools, webflow mcp-remote, and one custom Python MCP

What I saw

~100 Node processes
20+ Python processes
~5 MCP servers per conversation
18 conversation generations x ~5 MCPs = ~90 stale MCP processes

Each conversation was leaving its own MCP bundle under the long-lived Codex.app -> codex app-server tree. Finished conversations were not going back to a small baseline.

The extra part on my side

The main thing i did not see called out clearly yet is what happened on quit.

When I quit Codex from the Dock on March 17, 2026, most children died, but cleanup was only partial:

  • Node count dropped from about 100 to about 10
  • some MCP processes survived and were reparented to PID 1 / launchd
  • I found survivors still alive from March 9, 2026
  • I also had two old Codex chrome_crashpad_handler processes still alive from March 9 and March 14

I also saw what looks racey. In one spawn generation, most siblings from that batch were gone, but one twitterapi-docs-mcp survivor was still there by itself.

Why I think this matters

#10710 makes me think the stdio process-group cleanup on drop exists already. So maybe there are two gaps:

  1. old conversation state is sometimes not getting dropped in the desktop app
  2. when quit starts, some children still escape the final teardown path

One control point from the same machine: Claude Code via Superset.app only had about 11 MCP processes from 3 active sessions, and those were cleaned up normally. So this did not look like a generic macOS "too many MCPs" problem.

dorukardahan · 5 months ago

Small timing clarification on my earlier comment

One detail i want to tighten up from my earlier note here:

The orphan set i described was real right after Cmd+Q on March 17, 2026.
At that moment, most Codex child processes died, but i still had a small PID 1 / launchd residue:

2x `chrome_crashpad_handler`
2x orphaned `playwright-mcp`
1x orphaned `twitterapi` MCP

Later, after I reopened Codex and closed it again, most of those leftovers finally disappeared.

So my main point is not "every orphan stayed forever".
It is: one quit cycle still left a small orphan set when the expected number should have been zero.

That still feels consistent with the two-part picture @gabrielbryk and @RemarkRemedy were circling around:

  • accumulation while the app-server stays alive
  • then nondeterministic cleanup on quit, where most of the tree dies but a few children can still escape
whatsgrowth · 4 months ago

Fix implementation available

I hit this exact issue on a 16GB RAM Linux machine — running multiple Codex sessions with MCP servers (desktop-commander, context7, playwright, exa) accumulated 562 orphaned processes consuming 26GB of swap, triggering OOM kills and complete system freezes.

After investigating the source, I traced the root cause and implemented a fix. The branch is here:
👉 https://github.com/whatsgrowth/codex/tree/fix/mcp-process-cleanup (diff)

Root cause

McpConnectionManager holds a HashMap<String, AsyncManagedClient> but has no explicit cleanup. Wrapped in Arc<RwLock<>> inside SessionServices, the Arc<Session> reference count may never reach zero (held by spawned tasks, event channels, etc.), so ProcessGroupGuard::drop() never fires — and MCP server processes live forever.

The low-level cleanup already works correctly: ProcessGroupGuard in rmcp_client.rs properly implements Drop with killpg(SIGTERM) → 2s grace → killpg(SIGKILL). The problem is simply that it's never triggered.

The fix (48 additions, 0 deletions, 2 files)

1. core/src/mcp_connection_manager.rs — Add shutdown() method:

pub(crate) fn shutdown(&mut self) {
    self.clients.drain();
}

2. core/src/codex.rs — Call it in Session::shutdown():

sess.services.mcp_startup_cancellation_token.lock().await.cancel();
sess.services.mcp_connection_manager.write().await.shutdown();

3. core/src/mcp_connection_manager.rs — Safety net Drop:

impl Drop for McpConnectionManager {
    fn drop(&mut self) {
        if !self.clients.is_empty() {
            warn!("McpConnectionManager dropped with {} active client(s); cleaning up", self.clients.len());
            self.clients.drain();
        }
    }
}

4. core/src/codex.rs — Also clean up in refresh_mcp_servers_inner:

manager.shutdown();
*manager = refreshed_manager;

Verified

  • cargo check -p codex-core ✅
  • cargo test -p codex-core --lib -- shutdown — 7/7 pass ✅
  • Manual test: started Codex with MCP servers, ran a task, exited → pgrep confirmed all MCP processes were killed on exit ✅

Could not open a PR directly (repo restricted to collaborators), so posting the fix here. Happy to rebase if needed.

jaegerstrength · 4 months ago

Additional macOS desktop-app evidence for this issue on April 6, 2026.

I verified a live Codex.app session where this is happening with exactly one configured Playwright MCP server in ~/.codex/config.toml:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Current live parent process:

  • /Applications/Codex.app/... codex app-server --analytics-default-enabled
  • PID 68203

All leaking Playwright MCP descendants are parented to that single live app-server, not to old dead app instances.

Observed process tree totals:

  • 55 npm exec @playwright/mcp@latest wrapper processes
  • 55 node .../playwright-mcp child processes
  • 110 total Playwright MCP descendants

Observed RSS:

  • wrappers: about 241.6 MB
  • node children: about 106.8 MB
  • total descendants: about 348.4 MB

Important details:

  • there is only one configured Playwright MCP server entry, so this is not duplicate config
  • the processes appear in repeating wrapper/child pairs over time during one live desktop-app session
  • restarting Codex clears the pile temporarily, but a new app-server begins accumulating fresh Playwright MCP descendants again

This looks consistent with an app-side stdio MCP lifecycle/reaping bug rather than a user config problem or a one-off stale subtree.

Related issue that also seems relevant from the Playwright side: #14773.

ZWhiteTrace · 4 months ago

Still reproducing on latest versions as of 2026-04-15.

Environment

  • Codex.app 0.119.0-alpha.28
  • Homebrew codex CLI 0.120.0 (invoked as codex mcp-server by an external client)
  • macOS 15.5 (24F74), Apple Silicon

Evidence — ps -eo pid,etime,command:

89227       04:10  codex mcp-server
 9239    04:32:55  codex mcp-server
35505    05:56:57  codex mcp-server
63171    11:34:26  codex mcp-server
41760    01:06:22  node .../codex-playwright-mcp-cache/.../playwright-mcp
78476    09:20:59  node .../codex-playwright-mcp-cache/.../playwright-mcp
 7298    11:13:36  node .../codex-playwright-mcp-cache/.../playwright-mcp
75105    11:29:09  node .../codex-playwright-mcp-cache/.../playwright-mcp

4 playwright-mcp children, oldest at 11h29m. 4 codex mcp-server parents, oldest at 11h34m. None correspond to an active session; they are leaked from sessions that ended hours ago. /tmp/codex-playwright-mcp-cache at 253 MB.

Consistent with the 2026-04-06 Playwright-MCP comment above — still present on 0.119/0.120.

RedesignedRobot · 4 months ago

Still reproduces on v0.120.0 / Codex Desktop 26.409.20454. We observed 213 leaked @playwright/mcp process pairs (426 processes, 13.6 GB RSS). Filed as #17832.

PR #17223 (linked to #16895, merged April 10) fixed WebSocket client disconnect only. Subagent MCP teardown remains broken. See also #17574.

Root cause analysis with proposed fix: #17832 (comment)
https://github.com/openai/codex/issues/17832#issuecomment-4247026597

Update (2026-04-19): patch ready on branch RedesignedRobot:codex:fix/mcp-subprocess-cleanup, rebased on current main, cargo check -p codex-core -p codex-mcp clean. 2 files, +23/-2, covers both the Op::Shutdown path and the submission_loop channel-close fallthrough. Awaiting invitation to open as PR per the invitation-only contribution policy.

luohoa97 · 4 months ago

I get the memory leak on the Linux codex app port as well https://github.com/EvickaStudio/codex-app-linux-port
It spawns zombie MCP processes that eat 8gb of ram, my system regularly has to kill my browser tabs to keep the system from crashing. I think it's related to playwright as I have playwright as well.

To reproduce:

  • Install the codex app 26.409.20454
  • Install playwright MCP
  • Open multiple conversations with the MCP server enabled
  • Ram usage should leak over time with more zombie processes being created and you should get 8gb used over a few conversations.
m13v · 4 months ago

hit the same class of leak running a bunch of stdio MCP servers on macOS. the real culprit is process group handling, if you spawn the child without setsid/setpgid the parent can't send SIGTERM to the whole tree on exit, so npm/uv wrappers leak their node grandchildren. also node/npm wrappers don't forward SIGTERM to the real mcp binary by default, you need to exec the server directly or wrap with tini. and any stdio mcp needs an EOF-on-stdin watchdog inside the server so it self-exits if the parent dies without signaling. zombie reaping is table stakes but won't fix the reparented-to-launchd survivors, only pgid teardown does.

luohoa97 · 4 months ago

<img width="2481" height="1169" alt="Image" src="https://github.com/user-attachments/assets/49a0f852-aec3-4693-9f0a-8672ed531ce5" />
I got a new codex client so this is a different reproducibility process.

  1. Clone https://github.com/ilysenko/codex-desktop-linux
  2. Run the rpm build script
  3. Launch codex
  4. You should get 26.416.11627
  5. Use it for a while and you should get the leak.

Note: Chromium is running on my system as a flatpak and codex isolates the codex renderer and MCP processes.

luohoa97 · 4 months ago

Personally I just disabled the oh my codex MCP servers to save memory and slow down the accumulation of zombie processes. As for every conversation it spawns more duplicate zombie MCP processes that never get freed. This is a bug where for each conversation it just creates MCP servers, but it should be shared between conversations on start.

bingyizhou6u · 4 months ago

I’m seeing what looks like the same Codex Desktop MCP lifecycle leak on macOS.

Environment:

  • Codex Desktop app, macOS
  • Observed Codex app-server process: /Applications/Codex.app/Contents/Resources/codex app-server
  • MCPs involved: chrome-devtools-mcp, gitnexus mcp, Codex node_repl

Symptoms:

  • Codex Desktop repeatedly accumulates local MCP / REPL child processes under the same app-server.
  • This is not just normal Chrome multi-process behavior. The large process count is mostly MCP wrappers and node-based MCP servers launched by Codex.
  • The process count grows again after manual cleanup and continued Codex usage.

Observed before cleanup:

  • chrome-devtools-mcp: about 368 matching processes
  • gitnexus mcp: about 186 matching processes
  • node_repl: about 93 matching processes
  • chrome-devtools-mcp alone was roughly 19 GB RSS in one snapshot
  • gitnexus mcp was roughly 8 GB RSS in one snapshot

Relevant process pattern:

/Applications/Codex.app/Contents/Resources/codex app-server
  ├─ npm exec chrome-devtools-mcp@latest --channel stable --viewport 1440x960 --no-usage-statistics
  │   └─ chrome-devtools-mcp
  ├─ node /opt/homebrew/bin/gitnexus mcp
  └─ /Applications/Codex.app/Contents/Resources/node_repl

Manual cleanup results:

  • Killing stale chrome-devtools-mcp, gitnexus mcp, and node_repl processes immediately reduced the process count.
  • After cleanup, the system returned to roughly:
  • chrome-devtools-mcp: 0 initially, later restarted only when needed
  • gitnexus mcp: 2
  • node_repl: 1
  • Regular Google Chrome browser processes were not the source of the large count and were not killed.

Expected behavior:

  • Codex Desktop should either reuse MCP server processes or reliably terminate per-session MCP/REPL stacks when a session/thread/subagent no longer needs them.
  • Background or stale conversations should not leave hundreds of MCP server processes alive.

Actual behavior:

  • MCP/REPL processes accumulate under Codex app-server over time.
  • Manual cleanup is required to recover memory and process count.
leojkwan · 4 months ago

+1 confirming this is still active on Codex Desktop 26.422.x as of 2026-04-26, with a different MCP/feature manifestation worth naming explicitly: the Computer Use subsystem under codex app-server. This reinforces what @bingyizhou6u flagged on 2026-04-25 with concrete pid-tree numbers.

Environment

  • macOS Darwin 25.3 (Sequoia), Apple Silicon, 64 GB RAM
  • Codex Desktop, Computer Use enabled, ~17h continuous uptime
  • 1 active codex app-server --analytics-default-enabled parent

Process tree at peak

  • ~100 Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient (4–16 MB RSS each)
  • ~30 Codex.app/Contents/Resources/node_repl (4–7 MB RSS each)
  • All parented under the single codex app-server pid (not adopted by launchd, not detached)
  • Healthy steady-state observed post-cleanup: ~4 of each (the active worker pool)

Why Activity Monitor shows 24+ GB for "Codex"
The individual RSS numbers above are tiny — the headline number is macOS's compressor pool, not resident memory. vm_stat showed:
\\\
Free: 1.0 GB
Active: 14.2 GB
Inactive: 14.1 GB
Wired: 8.0 GB
Compressor: 25.7 GB ← here
Swap I/O: 66K in / 399K out
\\\
Compressed pages get attributed back to whichever process owned them — so 100+ small worker working sets that got compressed under pressure and never freed showed up as a single 24.5 GB "Codex" attribution and triggered the macOS "Your system has run out of application memory" Force-Quit dialog.

Workaround (narrowly-targeted, does NOT touch Codex.app, codex app-server, the active worker pool, or any other process)
\\\bash
pkill -f 'Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient'
pkill -f 'Codex.app/Contents/Resources/node_repl'
\\\
After running, free RAM moved 1.0 → 2.7 GB instantly; Codex respawned the correct ~4 workers from the active pool. Confirms these are leaked, not active.

Repro signal (one-liner check):
\\\bash
ps -axo pid,command | grep -cE 'SkyComputerUseClient|node_repl'
\\\
Healthy: 4–8. Leak active: 20+ and growing with uptime. Counts grow monotonically with Computer Use automation runs over time.

Suggested fix surface (consistent with #18881 and #17832): whatever invokes the Computer Use MCP tool needs to child.wait() / SIGTERM the spawned worker pair when the tool call resolves, the same lifecycle gap the broader MCP-reaping issue describes — Computer Use is just one more affected MCP host in the same pattern.

ideaitor · 4 months ago

Adding evidence on two more stdio MCPs in the same leak family on Codex Desktop.

Environment

  • Codex.app 26.422.30944 on macOS Darwin 24.6.0, 10-core arm64, 24 GB RAM
  • One live codex app-server --analytics-default-enabled parent (PID 9529)
  • Configured stdio MCPs: playwright, lighthouse (local), supabase, heroku

Affected MCPs (in addition to those already reported)

heroku (heroku mcp:start):

  • Spawn chain: bash heroku mcp:start → 3 levels of bash wrappers → node run mcp:start → node heroku-mcp-server.mjs
  • The CLI also fires heroku plugins:inspect @heroku/plugin-ai as part of plugin discovery on every startup
  • After ~45 minutes of normal use, observed:
  • 8 heroku mcp:start bash wrappers parented to app-server
  • 8 heroku-mcp-server.mjs node processes
  • 4 npm exec heroku@latest --repl
  • 12 heroku plugins:inspect @heroku/plugin-ai processes — many with PPID=1 (parent bash chain died, signals not propagated; orphans reparented to launchd)
  • Combined: ~80 leaked heroku-related processes, ~250% CPU, ~2 GB RAM
  • This compounds the issue: even if the Codex side adds setsid/killpg, Heroku's bash wrapper chain detaches plugins:inspect from the process group, so existing orphans wouldn't be cleaned up retroactively. New spawns under a process group would be fine.

lighthouse (local stdio MCP):

  • Single node /Users/steve/.codex/lighthouse-mcp-local/server.js config
  • After same window: 12 lighthouse-mcp-local/server.js processes + 7 Codex.app/Contents/Resources/node_repl processes, all parented to the live app-server
  • Each node_repl appears paired with a lighthouse spawn — confirms what bingyizhou6u and leojkwan reported about node_repl being part of the stdio MCP host pattern

System impact at peak

  • Load avg: 39.20 on a 10-core box
  • CPU idle: 0.10%
  • Free RAM: 583 MB (heavy swap thrashing — 15.9M swapins / 17.6M swapouts)
  • Codex Helper (Renderer) at 149% CPU — mostly stuck waiting on the dying MCP IPC

Workaround applied

  • Set enabled = false on [mcp_servers.heroku] and [mcp_servers.lighthouse] in ~/.codex/config.toml
  • pkill -f "lighthouse-mcp-local/server.js", same for heroku patterns
  • Load dropped 39 → 4.7, free RAM recovered immediately
  • Running a local watchdog (5-min launchd job) that detects duplicates of allowlisted MCP commands and kills all but the newest PID, until the upstream fix lands

Notes for the suggested fix
The m13v comment on this issue covers the right surface. Adding two practical points from the heroku case:

  1. setsid + killpg in Codex would solve it cleanly — even with Heroku's leaky bash chain, every descendant inherits the process group at fork time.
  2. For stdio MCPs whose CLI wrappers chain through bash without exec, an EOF-on-stdin watchdog inside the MCP server (per m13v) is the only thing that will reliably kill currently-running orphans whose parent died ungracefully. setsid/killpg is the right primary fix; the EOF watchdog is a robustness backstop.

Happy to provide more raw ps output or repro logs if useful.

Panlelaila · 4 months ago

I can reproduce a closely related variant of this on macOS, but specifically with the bundled Computer Use helper processes.

Environment:

  • Codex App: 26.422.30944 (2080)
  • macOS: 26.3.1 (25D2128)
  • Architecture: arm64
  • Bundled plugin: computer-use@openai-bundled / computer-use plugin version 1.0.758

What I observed on April 28, 2026:

  • ~/.codex/config.toml had plugins."computer-use@openai-bundled".enabled = true
  • Codex had accumulated 107 instances of:

./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp

  • All of them were children of the same desktop app process subtree:

/Applications/Codex.app/Contents/MacOS/Codex
-> /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
-> many SkyComputerUseClient mcp

  • The helper binary path resolved to the bundled plugin cache:

~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/.../SkyComputerUseClient

  • Combined RSS for those SkyComputerUseClient processes alone was about 1.26 GB (average ~11.8 MB each).
  • Several of the helpers had been alive since the same app session that started around 2026-04-28 08:10, so these were not short-lived one-shot helpers.

Important narrowing signal:

  • I manually cleaned them up with pkill against SkyComputerUseClient / SkyComputerUseService.
  • After cleanup, I re-ran only ordinary non-Computer-Use shell actions inside Codex (pwd, date, sed ... package.json) and repeatedly re-checked process counts.
  • The count stayed at 0, and neither SkyComputerUseClient nor SkyComputerUseService immediately came back.

That makes this look narrower than “all Codex activity leaks MCP children”.
It looks more like a lifecycle / teardown bug in the bundled computer-use plugin path, or in how app-server manages that MCP/helper subtree after the helper has been activated.

So this may be the same general cleanup class as this issue, but with a more specific reproduction target:

  • desktop app
  • computer-use@openai-bundled
  • SkyComputerUseClient mcp
  • lingering under codex app-server after prior usage instead of being reaped

If helpful, I can also provide a process-tree snapshot and exact command output showing the parent/child relationships.

shane9coy · 3 months ago

Additional repro: Computer Use / SkyComputerUseClient CPU fanout

I hit what looks like the same MCP lifecycle/leak family, but with a narrower Computer Use-specific trigger that may help isolate one upstream fix surface.

Environment

  • Codex Desktop: 26.506.31421 (CFBundleVersion 2620)
  • macOS: 26.3.1 (25D771280a)
  • Darwin: 25.3.0, arm64
  • Machine: M3 MacBook Air, 16 GB RAM
  • Computer Use plugin enabled: computer-use@openai-bundled

Symptom

Codex Desktop would spike into the 200-300% CPU range on normal prompt completions. CPU temps went over 220°F and the machine became close to unusable.

At peak I observed:

Codex                       ~248-264% CPU
Codex Helper (Renderer)     up to ~176% CPU
WindowServer                ~28-44% CPU
codex app-server            ~34% CPU during one spike

In one spike, the MCP/process fanout under the same codex app-server also multiplied:

10x SkyComputerUseClient mcp
10x uvx minimax-mcp
10x uvx minimax-coding-plan-mcp
11x relay_mac_arm64 --mcp

The local Codex log DB was also writing heavily during the spike:

~/.codex/logs_2.sqlite-wal: 80M
inserted_rows=1257 over 16 seconds
rows_per_second=78.56

Failure mode 1: SkyComputerUseClient inserted into turn-ended

My ~/.codex/config.toml had been rewritten into this shape:

notify = [
  "/Users/<user>/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient",
  "turn-ended",
  "--previous-notify",
  "[\"\\/Users\\/<user>\\/.codex\\/scripts\\/codex-notify-wrapper.sh\",\"turn-ended\"]"
]

That means ordinary prompt completions were routed through SkyComputerUseClient before reaching the lightweight previous notifier.

As a result, this path could fire on every normal response:

Codex finishes a normal prompt
-> turn-ended notify hook fires
-> SkyComputerUseClient wakes up
-> Computer Use / MCP / app-server plumbing wakes up
-> Electron renderer / GPU helpers wake up
-> WindowServer gets pulled into extra compositor work

That seems like the wrong place for SkyComputerUseClient. The user-facing notify hook is a high-frequency lifecycle hook for normal prompt completions. It should stay lightweight and bounded.

Workaround for failure mode 1

I backed up ~/.codex/config.toml and restored notify to a lightweight wrapper:

notify = ["/Users/<user>/.codex/scripts/codex-notify-wrapper.sh", "turn-ended"]

Then I fully restarted Codex Desktop to clear the already-spawned MCP/process tree.

After restart and another prompt:

notify stayed clean
1x SkyComputerUseClient mcp
1x Unity relay
1x MiniMax MCP pair
Codex main process around 2-3%
Renderer around 8%
app-server around 14%

Initially, this stopped the largest runaway. Computer Use could remain enabled for a short test. The critical fix for this first failure mode was removing SkyComputerUseClient from the turn-ended notify wrapper path.

Failure mode 2: Computer Use fanout even after notify stays clean

After more testing, I reproduced a second related failure mode. notify stayed clean:

notify = ["/Users/<user>/.codex/scripts/codex-notify-wrapper.sh", "turn-ended"]

But with computer-use@openai-bundled enabled, normal prompt/session activity still caused Computer Use-related children to respawn under codex app-server:

SkyComputerUseClient mcp
relay_mac_arm64 --mcp
uvx minimax-mcp
uvx minimax-coding-plan-mcp
node_repl

This points to a deeper Computer Use / MCP lifecycle problem, not a general claim that all user MCP servers are bad. The important narrowing signal is:

  • the bad notify wrapper is one reproducible trigger
  • even after fixing notify, computer-use@openai-bundled can still recreate SkyComputerUseClient / MCP child-process fanout
  • disabling only Computer Use stopped the SkyComputerUseClient fanout in my local containment test

So I think SkyComputerUseClient should only wake for explicit Computer Use actions. It should not be started by normal prompt completion or ordinary session lifecycle work.

Suggested upstream fix

I think there are three related fixes here:

  1. Do not insert SkyComputerUseClient into notify = ["...", "turn-ended"].

turn-ended fires after normal prompt completions. It should not bootstrap Computer Use / MCP plumbing unless a Computer Use action was explicitly requested.

  1. On startup, detect and migrate this bad config shape back to the previous notifier.

If Codex sees:

``toml
notify = [".../SkyComputerUseClient", "turn-ended", "--previous-notify", "..."]
``

it should unwrap it back to the previous lightweight notifier, or at minimum warn the user and refuse to use SkyComputerUseClient as a lifecycle notify handler.

  1. Tighten Computer Use process lifecycle under codex app-server.

When computer-use@openai-bundled is enabled, SkyComputerUseClient mcp instances should converge back to a small stable baseline after tool/session work. If normal prompt activity can create repeated Computer Use client stacks, those children need explicit ownership, teardown, and process-group cleanup.

This seems related to the broader MCP child lifecycle issue in this thread. The additional narrowing here is that Computer Use / SkyComputerUseClient can reproduce the runaway both through a bad notify wrapper and through plugin lifecycle/fanout even after notify is corrected.

Quick user-side check

Anyone hitting this can check:

rg -n 'notify|SkyComputerUseClient' ~/.codex/config.toml
ps -axo pid,ppid,%cpu,%mem,rss,comm,args | rg 'Codex|SkyComputerUse|relay_mac_arm64|mcp' | rg -v 'rg |/bin/zsh'

If notify starts with SkyComputerUseClient, try backing up the config, restoring notify to the previous lightweight notifier, and fully restarting Codex Desktop.

If notify is clean but SkyComputerUseClient mcp keeps multiplying, try disabling only computer-use@openai-bundled as a containment test. I would not treat unrelated MCP servers as the first suspect unless their own process counts are also multiplying.

etraut-openai contributor · 3 months ago

The bug reported by the OP has been fixed. If you are seeing a similar behaviors in the latest version of the app, please open a new bug report.

shane9coy · 3 months ago

Update after deeper local repro/debugging:

I want to correct the likely root-cause framing from my earlier comment. The Computer Use / MCP child-process fanout may have amplified the issue, but the strongest evidence now points to a huge text-like workspace artifact triggering the Electron/V8 hot path.

In the affected workspace, there was a generated embedded HTML file around 205MB. After moving that file out of the Codex-watched project root, the behavior improved substantially. The file was not an .xlsx issue; the Excel files in the project were small and Codex did not appear to have them open.

My current working theory is:

  • Codex opened or scanned the project workspace.
  • The app encountered a very large embedded HTML file, likely containing inline data/assets.
  • Because HTML is text-like and previewable/searchable, Codex/Electron may have tried to read, index, render, search, summarize, or otherwise process the full file.
  • Sampling the hot Codex process showed Electron/V8/Node activity around stream reads, JS callbacks, buffer allocation, memory copying, and GC-like work.
  • MCP/tool child processes were duplicated during this period, but they were mostly low CPU individually. The direct CPU burner was the main Codex Electron process.

So I would reframe this as a possible Electron/workspace-ingestion bug involving very large text-like artifacts. MCP fanout may make the failure worse, but it may not be the original cause in this repro.

Suggested product-side guardrails:

  • Do not eagerly ingest, render, index, or summarize very large HTML/text artifacts from a workspace.
  • Add a size cap for previewable/text-like project files.
  • Treat huge embedded HTML files like binary artifacts unless the user explicitly opens them.
  • Avoid repeatedly respawning duplicate MCP/tool child processes while the main app is already processing a large workspace artifact.

This seems especially important for creative/game projects where generated HTML boards, embedded asset boards, image references, and exported visual docs can easily become hundreds of MB.

Hylouis233 · 1 month ago

Additional sanitized macOS evidence matching this issue's MCP-child lifecycle failure.

Environment

  • macOS 26.6 (25G5052e), Apple Silicon Mac16,11, 24 GiB RAM
  • ChatGPT/Codex desktop build 26.707.31428
  • 41 local MCP definitions in the global Codex config; 40 enabled

Observed process tree after reboot

Within about 29 minutes of app/session recovery:

  • ChatGPT root: 501 descendants, about 18.50 GiB descendant RSS
  • Codex app-server worker: 320 direct children, 492 descendants, about 16.86 GiB descendant RSS
  • System total: 1,157 processes, 351 Node processes, about 23/24 GiB memory used, 11 GiB compressed, and 3.84 GiB swap used

The earlier Jetsam snapshot recorded four active codex workers. Their ChatGPT/Codex coalition contained 1,201 active processes and about 48.89 GiB aggregate footprint.

A normal AppleScript quit request returned successfully but the ChatGPT root and Codex worker remained alive. I then captured the exact ChatGPT tree and terminated only those 502 members, rechecking process name and start time before any forced signal. Without rebooting:

total processes: 1,157 -> 558
Node processes: 351 -> 0
used memory: about 23 GiB -> 7.9 GiB
compressed memory: about 11 GiB -> 507 MiB
swap used: 3.84 GiB -> about 633 MiB

This machine also experienced a watchdog kernel panic after compressor segments reached 100% with 69 swapfiles. Another agent application contributed additional MCP trees, but the captured ChatGPT/Codex tree and the targeted before/after cleanup isolate a substantial Codex-side contribution.

The behavior appears proportional to active/restored workers multiplied by the global local-MCP set. Please consider process-group ownership/cleanup for each worker, parent-death signaling for MCP children, startup reconciliation of stale workers, and a regression test that verifies all MCP descendants exit after a task/app closes.

No username, hostname, IP address, absolute path, command argument, environment variable, credential, MCP server name, conversation content, session ID, UUID, PID, or raw core data is included.

morluto · 1 month ago

A deterministic child-reaping mechanism was found in Codex CLI 0.144.1 and is still present in the current source. It is now tracked in #32219.

ProcessHandle::terminate() kills the child and then aborts wait_handle, while that wait task owns the child and is the only code that calls wait. This affects the PTY/pipe exec helper and is separate from the stdio MCP shutdown path addressed by #19753.

ofekron · 1 month ago

The deterministic reaping problem needs an owned process-tree lifecycle, not just best-effort cleanup at task end.

I would model every spawned Codex/MCP process with: owning task/session id, process group, child pids, startup receipt, heartbeat, terminal reason, reap attempt, and reap receipt. The critical invariant is that completion of the visible task must not be considered final until owned subprocess cleanup has either succeeded or produced a visible cleanup-failed state with enough ids for repair.

I maintain Better Agent (https://github.com/ofekron/better-agent), where detached runners and helper processes are tracked as durable owner state for crash/restart recovery. If useful, a star helps other desktop-agent builders find it.

wy193777 · 1 month ago

Still reproducible on a current macOS desktop build, after #19753.

Environment

  • ChatGPT/Codex app: 26.715.72359 (CFBundleVersion 5718)
  • Bundled CLI: codex-cli 0.145.0-alpha.30
  • macOS arm64, 36 GiB RAM
  • 99 global MCP server entries in config.toml

I also checked the bundled CLI tag against the #19753 merge commit (4e0cf94) through GitHub's compare API: rust-v0.145.0-alpha.30 is 2,358 commits ahead and 0 behind, so the lifecycle fix is present in this build.

Live process-tree snapshot

After approximately 90 minutes of app uptime:

  • approximately 1,584 descendants under the live ChatGPT/Codex process tree
  • approximately 41.9 GiB summed RSS (an upper bound because RSS double-counts shared pages)
  • approximately 2.4 GiB summed RSS for the core app/renderer/app-server processes
  • direct children of the same live codex app-server included approximately:
  • 147 npm exec @playwright/mcp@latest wrappers
  • 146 npm exec @azure/mcp@latest wrappers
  • 145 npm exec chrome-devtools-mcp@latest wrappers
  • 48 npm exec mcp-remote wrappers
  • 290 node ./mcp/server.mjs processes
  • each wrapper also had its corresponding Node/native child process

The duplicate process ages were staggered throughout the app session. These were not PPID 1 orphans: they remained attached to the live app-server process.

This looks like a remaining lifecycle path where conversations/sessions stay loaded, so their per-session McpConnectionManager is never shut down. In that case the explicit shutdown added by #19753 exists but is never reached. The observed multiplication also matches #20883's per-session MCP ownership description.

A full app quit is the practical workaround reported in the related issues. I did not terminate this live instance during collection.

Feedback ID: 019f8c21-42cc-7993-9a3e-fe1cdde15482

bbingz · 1 month ago

Analysis (community)

Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

  • Issue under review: #12491 — Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak
  • Theme / radar cluster: MCP/helper processes not reaped (process-leak)
  • Reporter posture: static + local evidence where available; not claiming a maintainer invite.

Observed (from issue + public residual signal)

Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak ## What version of Codex CLI is running? codex-cli 0.98.0 (Codex.app GUI wrapper) ## What subscription do you have? ChatGPT Pro ## Which model were you using? o3 (via Codex.app GUI) ## What platform is your computer? macOS 26.3 (25D125), Apple M4 Max, 64GB RAM, arm64 ## What issue are you seeing? Codex.app spawns codex exec --full-auto worker processes for each worktree but never reaps t

Root-cause hypothesis

MCP/Node helper processes retained after task completion (GUI path especially) accumulate CPU/RAM; aligns with desktop OOM reports.

High-level fix outline (not a PR)

  • Explicit process group + wait/reap on task end and session close.
  • Cap concurrent helper children; surface unreaped count in diagnostics.
  • Fail-first: spawn mock MCP, complete task, assert zero orphan children.

Related

#12491 and desktop memory cluster (#33582, #32797).

Questions for maintainers

  1. Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
  2. Preferred residual anchor issue if several open threads describe the same mechanism?
  3. If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

Happy to refine with more measurements or code pointers. No unsolicited PR from me.

bbingz · 1 month ago

Analysis (community)

Residual analysis for #12491 (GUI: MCP child processes not reaped) — invitation-only. Long-open process-lifecycle residual; distinct from Windows WMI/taskkill mega-threads (not pile-on of denylisted storms). No unsolicited PR.

Deterministic evidence (code)

Code (5dd992acd3):

  • Test helper documents the fragility of process cleanup: codex-rs/mcp-server/tests/common/mcp_process.rs
  • uses tokio::process::Child with .kill_on_drop(true) (≈L82)
  • comments note kill_on_drop is not a guarantee (≈L39–L41, ≈L360)
  • Production MCP orchestration centers on codex-rs/codex-mcp connection manager (connection_manager / rmcp_client re-exports) — lifecycle of external Node/stdio MCP servers must be joined on task end and session close.
  • Local TRACE shows ongoing MCP manager activity: codex_mcp::connection_manager ≈1745 TRACE rows under codex-cli 0.146.0-alpha.6 sessions on this host (indirect signal of frequent connect/disconnect churn).

Root-cause hypothesis

Task completion / GUI session teardown does not always wait on MCP child process groups. kill_on_drop in tests acknowledges cleanup is best-effort; production paths that spawn helpers without a guaranteed join accumulate orphans → RAM/CPU growth over long Desktop sessions (adjacent symptoms on #33582 / #32797, different platforms).

High-level fix outline (not a PR)

  1. Process-group spawn + guaranteed wait on task end, thread close, and app-server shutdown.
  2. Cap concurrent MCP helper batches; surface unreaped-child count in doctor/diagnostics.
  3. Prefer one long-lived MCP connection manager over per-turn respawn where protocol allows.
  4. Fail-first: mock MCP server child; complete task; assert zero orphan PIDs (and that kill_on_drop is not the only line of defense).

Questions for maintainers

  1. Is reaping owned by app-server, desktop shell, or codex-mcp connection manager?
  2. Preferred test location for process-lifecycle (suite vs mcp-server tests)?
  3. Would an invited PR for join-on-complete + diagnostics be useful?

No unsolicited PR from me.

yanxiaolong01 · 23 days ago

Title:ChatGPT macOS app leaks zombie (defunct) child processes — exhausts
per-user process limit

App version: ChatGPT 26.730.61639 (Codex Framework 151.0.7922.71)
OS: macOS 14 (Darwin 23.2.0), Apple Silicon

Description:
The ChatGPT desktop app continuously accumulates <defunct> (zombie) child
processes without reaping them. The parent is the main ChatGPT process, and
the leak traces to the embedded Codex app-server / code-mode-host chain
(codex app-server → node_repl / codex-code-mode-host).

Rate: ~36 zombies/minute. After ~10 minutes of runtime the app held 400+
zombie processes.

Impact: On macOS the per-user process limit (kern.maxprocperuid) is 2666. At
this leak rate the app exhausts the process table in roughly an hour, after
which the entire system fails to fork new processes — every shell and app
throws fork failed: resource temporarily unavailable until ChatGPT is quit.
Quitting ChatGPT lets launchd reap all zombies instantly, confirming the app
is the sole cause.

Root cause (likely): child processes are fork()ed but the parent never calls
wait()/waitpid() to reap them.

Steps to reproduce:

  1. Launch ChatGPT desktop and leave it running (idle is enough; the

code-mode/agent host spawns subprocesses).

  1. Run ps -eo ppid,stat | awk '$2==<ChatGPT_PID> && $3 ~ /Z/' | wc -l

periodically.

  1. Observe the zombie count climb steadily and never drop.

Expected: child processes are reaped; zombie count stays near zero.
Actual: zombies grow unbounded until the OS process limit is hit.

bbingz · 22 days ago

@yanxiaolong01's process chain narrows the ownership question I raised above: codex app-server → node_repl / codex-code-mode-host is the code-mode host spawn path, not the stdio MCP server path that codex-mcp's connection manager owns. ~36 zombies/min with the parent still alive means the children exit and are never wait()ed — a missing reap on the host side, not a kill/teardown ordering bug.

Two things that would make this actionable:

  • @yanxiaolong01: ps -o pid,ppid,stat,command -p <zombie-pid> for a handful of the defunct entries, plus the PPID chain. Whichever process is the direct parent owns the wait(), and that decides where the fix goes.
  • Maintainers: same question as before, now scoped — does the code-mode host reap its node_repl children explicitly, or does it rely on drop-time kill the way the test helper does (codex-rs/mcp-server/tests/common/mcp_process.rs, .kill_on_drop(true) ≈L82, with the "not a guarantee" comment at ≈L39-41)?

Fail-first test unchanged: spawn a code-mode cell, complete the task, assert zero defunct children under the app-server PID. No unsolicited PR from me.

yanxiaolong01 · 22 days ago

Requested ps data (ChatGPT 26.730.61639 / Codex Framework 151.0.7922.71,

macOS 14.2 23C64, Apple Silicon)

Ran the scoped ps you asked for. The direct parent of the zombies is NOT
the app-server — it's the top-level native host process.

Zombie sample (ps -axo pid,ppid,stat,command):
71372 70992 Z <defunct>
71442 70992 Z <defunct>
71445 70992 Z <defunct>

PPID chain:
<zombie 71372> Z --PPID--> 70992 --PPID--> 1 (launchd)
70992 S /Applications/ChatGPT.app/Contents/MacOS/ChatGPT # top-level
native host, PPID=1
71348 S /Applications/ChatGPT.app/Contents/Resources/codex -c
features.code_mode_host=true app-server --analytics-default-enabled #
PPID=70992

Zombie parent distribution (own zombies only):
949 70992 <- ChatGPT top-level native host (the leak)
19 1506 <- Google Chrome (unrelated 3rd party)
3 70835 <- GoogleUpdater (unrelated 3rd party)

Key finding that scopes the fix:

  • codex ... code_mode_host=true app-server (PID 71348) currently has

zero child processes — it is not the direct parent of any defunct.

  • All code-mode defunct children reparent to / are owned by the **top-level

ChatGPT native host (70992)**, whose PPID=1.

  • So the missing wait() lives in the top-level host that actually spawns the

code-mode node children, not inside the app-server / MCP
connection-manager layer.

Rate: 70992-owned zombies went 972 → 981 in 15s (~36/min), parent stays in
state S (alive) the whole time — confirms a pure missing-reap, not a
kill/teardown-ordering bug.

hoklims · 22 days ago

Windows evidence: the leaked children are NOT orphans, and lifetime CPU cannot identify them

Adding a Windows data point that differs from most of the thread in two ways that I think are actionable. Cross-references #22992 (duplicate MCP servers across conversations) and #30753 (duplicate pools after RefreshMcpServers), which describe the same shape.

Environment

  • Windows 11 Pro 25H2, build 26200.8973, 63.7 GiB RAM
  • Codex Desktop OpenAI.Codex_26.730.8199.0_x64
  • codex.exe ... app-server --analytics-default-enabled, launched by ChatGPT.exe
  • 16 stdio MCP servers declared in config.toml
  • Claude Code also running on the same host, which gives a useful control group
1. Every leaked process had a LIVE agent ancestor

I walked the full ancestry of all 605 MCP/language-server processes rather than checking the direct parent. All 605 resolved to a live claude.exe or codex.exe ancestor. Zero were orphaned.

A parent-is-dead check finds nothing here, which is why this can look like "no leak" to tooling that only looks one level up. The processes are attached to a live app-server and simply never serve again.

Attribution by owning root:

| root | direct children | shape |
|---|--:|---|
| claude.exe #79308 | 16 | exactly one of each server |
| claude.exe #43492 | 21 | ~one of each |
| claude.exe #38668 | 19 | ~one of each |
| codex.exe #81384 | 213 | 59 node, 42 graphify, 28 serena, 28 cocoindex, 13 vault-semantic, … |

Totals: codex #81384 owned 454 of the 605. The three Claude Code sessions owned 40–60 each.

2. Spawn timeline: complete fleets, repeatedly, never reaped

33 processes = one full fleet of my 16 servers. Creation timestamps for codex #81384's direct children:

09:39  ###################  19
09:40  ################     16
09:42  ################     16
10:19  ############################################################  63
10:32  ################################  32
10:38  ################  16
10:40  #########################  25
10:41  #########################  25

Roughly 13 fleets in about an hour. No previous fleet was terminated.

3. The discriminator: lifetime CPU is useless, windowed CPU is not

This is the part I have not seen stated in the thread, and it matters for anyone writing cleanup logic.

Several of my servers load an ML model at startup. Each vault-semantic instance burns 9–13 s of CPU importing torch and loading BGE-M3 before it ever listens. So a "has it done work?" test based on lifetime CPU classifies 7.5 GiB idle duplicates as busy and keeps them.

Sampling CPU over a live window instead is blind to startup cost:

668 of 669 MCP processes consumed ZERO CPU over a 25-second window

Example of the two figures disagreeing on the same process:

vault-semantic pid=48224  lifetimeCpu=13.4 s  windowCpu=0 s  age=48 min  priv=7493 MiB
4. Cost
  • 147 GiB of commit charge held by instances beyond the first per (root, server)
  • Host reached 95.1 % commit (243 GiB / 255.7 GiB), 3.7 GiB available
  • Windows logged 5 × Resource Exhaustion (Event ID 2004), naming vmmemWSL and two python.exe at 7.86 GiB each

Terminating all-but-newest per (root, server), restricted to processes idle over a live window, reclaimed 93.9 GiB and took commit from 95 % to 42 %. Nothing broke: the newest instance under each root is the one the session is actually using.

5. Suggestion

Whatever the eventual fix (#20883's project-scoped pool would remove the class entirely), a teardown heuristic that keys on liveness of the parent will not catch this, and one that keys on lifetime CPU will keep the most expensive offenders. Keying on "newest instance per (owning agent, server)" plus a windowed idleness check identified 499 of 669 processes correctly here with no false positives.

Happy to provide the raw per-process table or re-run any specific measurement.

yanxiaolong01 · 21 days ago

Environment

  • macOS: 14.2 (Sonoma)
  • ChatGPT Version: 26.803.41515 (Build 6321)

Verification

Tested on the latest version (26.803.41515) with real-time
monitoring:

  • Total processes: Stable at 12-13
  • Zombie processes: 0
  • Process state distribution: All in S (sleeping) or R (running) state

Conclusion

Issue Resolved: Version 26.803.41515 no longer exhibits
the zombie subprocess accumulation issue.

etraut-openai contributor · 21 days ago

This thread conflates several different problems. That makes it difficult to tell which of these have been fixed and which still exist. I can say with high confidence that the original bug reported in this thread was fixed, which is why I initially closed the issue. It looks like it was reopened at some point because similar symptoms were reported. There is at least one other bug related to ProcessHandle::terminate() that is a real bug, and I'll work on a fix for that one.

If you are seeing other bugs that involve process leaks, please open a new issue and provide details so we can track it independently.

bbingz · 21 days ago

Thanks @etraut-openai — agreed this thread conflated several process-lifecycle failures.

My earlier residual notes were aimed at that same split (owned-process reaping / ProcessHandle::terminate() vs the original Desktop zombie report). Standing down here; will only open a new issue if I can reproduce a distinct residual with a clean repro.

etraut-openai contributor · 20 days ago

The ProcessHandle::terminate() issue will be addressed in the next release, so I'm going to close this. As I mentioned above, if you see similar symptoms, please open a new bug report. Thanks!

bbingz · 20 days ago

Thanks @etraut-openai — appreciated the split clarification and the upcoming ProcessHandle::terminate() fix. Standing by for the next release; will only open a fresh issue if a distinct residual shows up with a clean repro.