Windows: cua_node kernels & server.mjs processes accumulate across sessions (78 processes / 39h), holding GBs of commit charge #46833

Environment

• Windows 11 Pro build 26200, 32 GB RAM
• codex-cli 0.153.4; cua_node runtime build df473e5367fa2b42
• Parent processes are Codex app processes (codex.exe) and their cmd.exe wrappers

Summary

cua_node child processes are not reaped when sessions end. After about 1.5 days of intermittent use I found 78 leaked processes:

• 71 × node / node_repl launched from %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<build>\bin\, including ./server.mjs instances; parents are codex.exe / cmd.exe / node
• Their creation times cluster at 0.4 / 1.3 / 3 / 4.9 / 7.6 / 13.4 / 27.2 / 30.6 / 32.2 / 39.2 h — one batch per session, and none of the older batches was ever reaped
• Old processes were fully paged out (~0 working set) but still held ~1.4 GB of commit charge. Combined with other leaks on the same machine, system commit charge reached 93% and the machine became unusably laggy

Workaround verified

Killing only signature-matched node / node_repl / cmd processes older than 2 h (while protecting the active session's process tree) took node count from 125 → 19 and system commit from 80.3% → 68.8%, without disturbing any active session.

Expected behavior

• Session teardown terminates the full cua child tree. On Windows, job objects with kill-on-job-close would make this robust; per-process kill misses children when wrappers (cmd → node) are involved
• Stale kernels/servers whose session is gone should be reaped even if teardown was missed (e.g., on app restart, adopt and kill orphans older than the current app instance)

Related

• Desktop app (macOS): idle node_repl visualization kernels accumulate (60–70 concurrent, ~600 MB), causing severe input lag #39816 (macOS: idle node_repl visualization kernels accumulate, 60–70 concurrent) — same failure class; this report adds Windows and the cua_node runtime server.mjs processes with commit-charge measurements.