Desktop app (macOS): idle node_repl visualization kernels accumulate (60–70 concurrent, ~600 MB), causing severe input lag
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 execCLI runs were active — this is entirely the desktop app.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Confirming this on macOS 26.6, ChatGPT.app 26.818.21641 (6849), Codex CLI 0.149.1.
Same symptom, two additions:
codexCLI process (installed via@openai/codexnpm package,/opt/homebrew/lib/node_modules/@openai/codex/...), not just ChatGPT.app's bundled Codex Framework. Different PPIDs, same leak pattern.cua_node/bin/node_replhad 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.Manual
killon 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.