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 exec CLI runs were active — this is entirely the desktop app.

Start by reproducing the macOS desktop-app workload and inspecting the cua_node/bin/node_repl processes, their kernel.js sessions, and the codex sandbox supervisors described in the report. Trace how visualization/REPL work is completed and how those processes are reaped; done means completed work promptly removes idle kernels or keeps them within a bounded pool without the reported process and memory growth.