macOS Desktop: completed recurring automations retain CUA node_repl workers #35582

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   computer-use

   automations

   performance

   on Jul 27, 2026
2. github-actions commented on Jul 27, 2026

   

   github-actionsBot

   on Jul 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Desktop: bundled node_repl MCP processes leak one-per-thread, never reaped until app-server exit #35485

   Powered by Codex Action
3. gkze commented on Jul 27, 2026

   

   gkze

   on Jul 27, 2026

   More actions

   Adding a macOS datapoint that confirms the retention behavior, plus a downstream consequence I haven't seen documented in any of the related issues (#26984, #27601, #35485): the leaked pipes exhaust the global XNU pipe-buffer pool, which deadlocks unrelated processes on the machine — software that has nothing to do with Codex — at FD counts nowhere near any per-process limit.

   Environment

   ChatGPT Desktop 26.721.41059 / build 5848
   Bundled CLI: codex-cli 0.146.0-alpha.3.1
   Codex Framework 150.0.7871.128
   macOS 26.5.2 (25F84), Darwin 25.5.0, arm64
   

   Retention datapoint (matches this issue)

   • 36 node_repl hosts under one codex -c features.code_mode_host=true app-server after ~2.5 h of light use, all sleeping (S), ~0.08 s total CPU each.

   • Spawn times cluster in bursts of 2–3 within seconds (e.g. 11:20:50, 11:20:58, 11:21:05), consistent with recurring-automation runs rather than interactive threads.

   • Only 3 of 36 had live workers (node kernel.js --session-id … + codex app-server --listen stdio://) under them; the rest were childless and hours old.

   • Each retained host pins ~13 pipe ends: ~5 on the app-server side (stdio + control pipes) and ~8 in the host.

   • The node_repl hosts are only the visible tip. Enumerating all children of the app-server shows every configured stdio MCP server and every enabled plugin's local MCP shim is retained the same way — roughly 50 full generations of the entire roster (~600 direct children), one generation per thread/automation run:

      52  uv tool uvx pagerduty-mcp
      52  uv tool uvx mcp-proxy-for-aws@latest …
      52  uv tool uvx markitdown-mcp@0.0.1a4
      52  …/1Password.app/Contents/MacOS/onepassword-mcp
      51  npm exec dotenv-cli … -- uvx mcp-proxy --transport streamablehttp …
      51  node …/bunx-…-mcp-remote@latest/…
      48  node …/bunx-…-@vantasdk/vanta-mcp-server/…
      45  node ./mcp/server.mjs --stdio     (plugin shims)
      45  node ./mcp/server.mjs
      45  node ./mcp/server.cjs --stdio
      20  npm exec <private mcp server>
      20  npm exec convex@latest mcp start
      18  npm exec xcodebuildmcp@latest mcp
      13  …/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl
     

     Each generation is ~20 processes (plus uvx/npx grandchildren). The app-server's own pipe FD count (1,701 at the snapshot above) matches ~3 stdio ends × ~570 retained children almost exactly — i.e. the same never-reaped per-thread lifecycle as this issue's node_repl workers, applied to every stdio MCP server. This looks like the same root cause class as MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE ("Too many open files", os error 24) #26984 / MCP server processes leak: per-thread processes never cleaned up (9+ GB RSS) #30408, observed from the Desktop app-server.

   Previously-undocumented consequence: global pipe-pool exhaustion deadlocks third-party processes

   XNU allocates pipe buffers from a small fixed global pool. With the app-server holding ~1,600 pipe ends (plus the retained hosts' ends), the pool exhausts, and new pipes are granted almost no buffer. At that point any process on the machine that writes a modest amount into a fresh pipe before a reader exists blocks in write() forever.

   The classic victim is a bash heredoc: bash writes the document into a pipe before exec'ing the command, assuming pipe-buffer capacity. Captured from a hung, completely unrelated process (direnv/nix-direnv sourcing an .envrc):

   execute_disk_command
     do_redirections
       do_redirection_internal
         write   ← blocked indefinitely; target pipe granted ~0 buffer
   

   Reproducible probe while the app-server holds ~1,600 pipe FDs (sizes in bytes):

   heredoc  700B: HANGS  (bash small-doc path: direct write into pipe)
   heredoc 4000B: ok     (bash switches to temp-file path, no pipe involved)
   heredoc 16000B: ok
   

   Practical impact here: every direnv export on the machine wedged permanently (nix-direnv writes its ~700 B reload script via heredoc), across multiple unrelated repos and terminals. Wedged writers never recover even after the pool frees — the pipe's buffer never grows and no reader ever appears — so each occurrence also requires hunting down and killing stuck processes.

   Two properties make this failure mode nasty to attribute:

   1. It breaks processes with no relationship to Codex, with no error — just a hang.
   2. It happens at ~1,600 FDs, far below ulimit -n-style limits, so none of the usual EMFILE symptoms from MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE ("Too many open files", os error 24) #26984/macOS: Codex Desktop/app-server appears to exhaust syspolicyd, causing spctl “Too many open files” globally #27662 appear first.

   Evidence supporting reap-on-completion as the fix

   SIGTERM-ing a childless (completed) node_repl host is handled cleanly today: the app-server notices the exit and promptly closes its side's pipe ends (parent FD count drops within seconds, verified repeatedly). So the graceful-teardown path already works — it's just never initiated. A reap when the run reaches a terminal state (or an idle timeout) would fully resolve the retention side.

   Interim workaround for anyone else hitting this — cull childless hosts older than a few minutes (completed runs; the live ones keep their kernel.js worker as a child):

   for as in $(pgrep -f 'features.code_mode_host=true app-server'); do
     for pid in $(pgrep -P "$as" -f node_repl); do
       [ "$(pgrep -P "$pid" | wc -l)" -eq 0 ] || continue   # has worker => active
       et=$(ps -p "$pid" -o etime= | tr -d ' ')
       case "$et" in
       *-* | *:*:*) ;;                                      # hours/days old
       *) [ "${et%%:*}" -ge 3 ] || continue ;;              # MM:SS, keep < 3 min
       esac
       [ "$(ps -p "$pid" -o ppid= | tr -d ' ')" = "$as" ] && kill "$pid"
     done
   done

   Note this only slows the bleed: the retained per-thread MCP server generations (the ~600-child table above) dwarf the node_repl share, and there is no safe external heuristic for distinguishing a dead thread's MCP servers from a live one's — so the pool still exhausts eventually and only an app-server restart resets it. A reap-on-thread-termination (or idle timeout) covering all per-thread stdio children, not just node_repl, appears to be the complete fix.