Desktop app (macOS): idle node_repl visualization kernels accumulate (60–70 concurrent, ~600 MB), causing severe input lag

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

What happened

During normal interactive use of Codex in the ChatGPT macOS desktop app, the embedded Codex engine accumulates dozens of idle cua_node/bin/node_repl processes — the sandboxed Node kernels spawned for the visualizations feature. Within ~45 minutes of app launch I observed 67 concurrent node_repl kernels, all at 0% CPU, ~10 MB RSS each (~580–700 MB combined), each wrapped in its own codex sandbox supervisor process, so the app's total process tree reached 138 processes / ~6.5 GB RSS.

Combined with the UI renderer growing to ~1.6 GB and staying busy (~40% CPU), this produced severe keyboard input lag in the app — keystrokes visibly queue. The machine (24 GB RAM) was pushed deep into swap (5.7 GB of 6 GB used within 45 minutes of a reboot).

Kernel reaping appears to exist but is far too slow: the count drifted 67 → 60 over about a minute of idle observation, while most kernels showed elapsed times of 18–20 minutes after their originating work had completed. At least one kernel had been alive 48+ minutes — the entire lifetime of the app process — suggesting some are never reaped. During an active session the spawn rate easily outpaces the reaper.

Evidence

Process count and per-kernel detail (usernames/paths redacted):

$ ps ax | grep -c "[n]ode_repl"
67    # later 61, 60 — slow drain while idle

$ ps -axo pid,ppid,%cpu,rss,etime,command | grep "[n]ode_repl" | head
  256 18253   0.0  10752    19:54 /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl
 7604 18253   0.0  10768    06:44 /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl
 8355 18253   0.0  10768    19:31 /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl
 8593 18253   0.0  10768    19:23 /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl
14346 18253   0.0   8000    48:29 /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl   <-- alive since app launch
...
579 MB across 57 node_repl kernels (all 0.0 %CPU)

All kernels are children of the main codex engine process (pid 18253 above, itself at ~812 MB RSS). Each kernel also has an accompanying codex sandbox wrapper of the form:

/Applications/ChatGPT.app/Contents/Resources/codex sandbox \
  -c default_permissions="node_repl" \
  -c permissions.node_repl={filesystem = {..., "~/.codex/visualizations/2026/08/20/<uuid>" = "write", "<workspace dir>" = "write", ...}, network = {enabled = false}} \
  -- .../cua_node/bin/node --experimental-vm-modules /var/folders/.../kernel.js --session-id <id> --working-dir <workspace dir>

The ~/.codex/visualizations/<date>/<uuid> write grants indicate one kernel per visualization/REPL artifact.

Aggregate app footprint at the time:

ChatGPT/Codex total: 244% CPU, 6.5 GB RSS across 138 procs
  67  cua_node/bin/node_repl        (idle kernels)
  25  Codex Framework helpers       (Chromium; renderer at 1.6 GB RSS, ~40% CPU, 10+ min CPU time in 42 min)
  16  Resources/codex               (engine + sandbox wrappers)
  14  ~/.codex/computer-use/Codex
  10  cua_node/bin/node

Expected behavior

Visualization kernels should be terminated promptly (seconds, not tens of minutes) once their visualization/REPL work completes, or a small bounded pool should be reused. Idle kernels should never survive for the lifetime of the app.

Impact

Severe keyboard/input lag in the desktop app during and after heavy Codex use; system-wide memory pressure (swap exhaustion) on a 24 GB machine. Fully quitting and relaunching the app clears it, which is the current workaround.

Environment

  • ChatGPT macOS desktop app 26.818.22352 (6872), bundled Codex Framework 151.0.7922.170
  • macOS 26.5.2 (25F84), Apple Silicon (14-core), 24 GB RAM
  • No codex exec CLI runs were active — this is entirely the desktop app.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 7 days ago

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

  • #38714
  • #38948
  • #38825
  • #38614
  • #38526

Powered by Codex Action

lemonluck01 · 4 days ago

Confirming this on macOS 26.6, ChatGPT.app 26.818.21641 (6849), Codex CLI 0.149.1.

Same symptom, two additions:

  1. Not desktop-app-specific. Some of the leaked pairs here were children of a standalone codex CLI process (installed via @openai/codex npm package, /opt/homebrew/lib/node_modules/@openai/codex/...), not just ChatGPT.app's bundled Codex Framework. Different PPIDs, same leak pattern.
  1. Paired with an MCP stdio server, not just the node_repl kernel. Every leaked cua_node/bin/node_repl had a matching orphaned MCP server process (a user-configured stdio MCP server, spawned via the same session) sitting alongside it — same lifecycle, same non-reaping. So this isn't isolated to the visualization kernel; whatever spawns/tracks per-session child processes for code-mode sessions generally isn't reaping them.
  1. Zero drain, not slow drain. Where the original report saw a slow drift (67 → 60) over ~1 minute of idle observation, mine showed literally zero reaping across multiple checks spanning the investigation — and the oldest surviving pair dated to Wednesday, roughly 4-5 days of continuous accumulation, not just one 45-minute session.
$ ps aux | grep -iE "ai-memory-mcp/server.mjs|cua_node/bin/node_repl" | grep -v grep | wc -l
116

$ ps aux | grep -iE "..." | awk '{sum+=$6} END {print sum/1024 " MB"}'
689.8 MB

# oldest surviving pair: spawned Wed 10AM, killed today (~4-5 days old)
# all confirmed 0.0% CPU - genuinely idle, not doing background work

Manual kill on the matched PIDs freed ~690 MB immediately with no ill effect on the live ChatGPT app or an active CLI session — consistent with this report's workaround, just without needing a full app restart.

Environment: macOS 26.6 (25G72), Apple Silicon.