Code-mode kernel respawned 5x for the same session-id; orphaned kernels are never reaped and grow to GBs (Windows desktop)

Start by tracing the codex-command-runner lifecycle and the kernel.js launches recorded in .codex.sandbox\sandbox..log, focusing on session-id reuse and parent-child cleanup on Windows. Reproduce the repeated launches if possible and verify that a prior kernel is terminated before replacement and that kernels do not remain after their runner exits.

What version of the Codex App are you using?

26.803.5235.0 (Microsoft Store package OpenAI.Codex_26.803.5235.0_x64)

What subscription do you have?

Pro

What platform is your computer?

Windows 11, 16 GB RAM

What issue are you seeing?

The code-mode kernel (cua_node node.exe running kernel.js) was respawned 5 times for the same --session-id and same --working-dir within 19 minutes. Four of those kernels were left orphaned (their parent codex-command-runner had exited), and none of them were reaped — they kept running and kept allocating memory for the next 7 hours until I killed them manually.

This is distinct from #34302 (that one is taskkill.exe/conhost.exe orphans and the reporter explicitly notes it is not memory pressure). Here the orphans are the code-mode node kernels, and they do cause severe memory pressure.

Timeline (from .codex\.sandbox\sandbox.<date>.log) — all five lines are the same session id 5bdaf690… and the same working dir:

01:29:49  START node.exe … kernel.js --session-id 5bdaf690… --working-dir …\1-worker-2-api-pdf-cloudflare
01:31:05  START node.exe … kernel.js --session-id 5bdaf690…   (same session)
01:44:25  START node.exe … kernel.js --session-id 5bdaf690…   (same session)
01:46:28  START node.exe … kernel.js --session-id 5bdaf690…   (same session)
01:48:47  START node.exe … kernel.js --session-id 5bdaf690…   (same session)

State ~7 hours later (08:46), before I intervened:

The last one was still actively burning >1 core (107%) seven hours after it was spawned, with no user interaction in that window.

System impact:

• Free physical memory down to 1.3 GB / 15.6 GB (8%)
• Pagefile in use 12.3 GB (peak 21.5 GB)
• Memory Compression at 837 MB
• The Codex UI itself became unresponsive (window Responding=True, backend app-server idle at 0.5%, but the UI would not react) — I initially misdiagnosed this as a Codex UI hang before finding the memory exhaustion
• Killing the 4 orphan pairs + the runaway kernel recovered ~5.6 GB and the UI became usable again

Orphan detection used: for each codex-command-runner, look up ParentProcessId; treat as orphaned if the parent no longer exists, or if the parent's CreationDate is later than the child's (PID reuse guard). Four of five matched.

What I could not determine: the log gives no error explaining why the first kernel needed to be respawned at all. The only recurring warning in that window is the (apparently harmless, always-present) hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed … 5. So the trigger for the respawn loop is unknown to me.

Suggested handling:

1. Before spawning a kernel for a session-id that already has one, terminate/reap the previous kernel for that same session-id.
2. When a codex-command-runner exits, kill its child kernel rather than leaving it running.
3. Consider a watchdog for kernels that exceed some CPU-time/wall-clock budget with no attached parent.

Happy to provide the full sandbox log excerpt if useful.