›_ Codex Issues
Codex Issues / #37746

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

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

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:

| kernel PID | spawned | parent codex-command-runner | RSS at spawn-time check | RSS when killed |
|---|---|---|---|---|
| 13136 | 01:29:49 | dead (orphan) | 97 MB | 1815 MB |
| 36892 | 01:31:05 | dead (orphan) | 117 MB | 151 MB |
| 39072 | 01:44:25 | dead (orphan) | 117 MB | 464 MB |
| 29308 | 01:46:28 | dead (orphan) | 94 MB | 2036 MB |
| 5660 | 01:48:47 | alive | 3914 MB | 1850 MB, 107% CPU, 2460s CPU accumulated |

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 18 days ago

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

  • #37672
  • #36971
  • #36958

Powered by Codex Action

9zrdh8dnyt-a11y · 12 days ago

Additional reproduction: attached CUA kernel grows beyond 2 GB and remains CPU-active

This adds a different failure mode to #37746.

The original report observed repeated kernel respawns and orphaned processes. In this case, exactly one live node_repl.exe broker retained one live node.exe kernel. The parent remained valid, but the child grew beyond 2 GB and continued consuming more than one logical processor after browser-control operations had completed.

This comment concerns kernel resource growth and lifecycle only. No user-visible performance impact was attributed to this process.

Environment

  • Codex Desktop: 26.810.7004.0
  • Windows 11 Pro 25H2, build 26200.9168
  • CUA runtime: 1cb4becc994cbb02

Process attribution

Codex traced the process tree through Win32_Process:

codex.exe
└─ node_repl.exe
   └─ node.exe --experimental-vm-modules <temp>\kernel.js

The child executable resolved to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\1cb4becc994cbb02\bin\node.exe

The command line contained kernel.js, the CUA session ID and the active working directory.

The node_repl.exe broker was effectively idle. The CPU and memory consumption came from the attached node.exe child.

Measurements

Codex measured CPU consumption from the change in accumulated process CPU time across a three-second interval. CPU rate below is expressed in logical processors, where 1.0 means one fully occupied logical processor.

| Observation | Kernel age | Working set | Private memory | CPU rate | Accumulated CPU | Threads | Handles |
|---|---:|---:|---:|---:|---:|---:|---:|
| First kernel | approximately 19.2 hours | 2.02 GB | 2.17 GB | 1.19 | 88,188.7 seconds | 14 | 235 |
| Replacement kernel | approximately 20 minutes | 1.01 GB | 1.17 GB | 1.18 | 2,214.1 seconds | 14 | 235 |

No browser-control call was executing during either CPU sample.

Isolation

Codex reset only the JavaScript kernel using the runtime's kernel-reset operation.

Before the reset:

node_repl.exe
└─ node.exe ... kernel.js

After the reset:

node_repl.exe

The node.exe child exited immediately. The broker and Codex Desktop remained running.

A later browser-control operation created a replacement kernel. Approximately 20 minutes after that kernel started, and after browser-control activity had ended, it exhibited the second set of measurements above.

Scope of the finding

This reproduction did not show:

  • multiple kernels for the same session;
  • a respawn loop;
  • a dead or reused parent PID;
  • or an orphaned kernel.

It shows that a single, still-attached CUA kernel can retain sustained CPU activity and rapidly growing private memory after browser-control work completes.

The measurements do not identify whether the retained activity is caused by an outstanding timer, promise, event subscription, browser object or another kernel-owned resource.

Expected behaviour

After browser-control work completes, the kernel should release the completed operation's state and return to bounded idle resource usage. If it cannot do so, the broker should retire or restart it.

Investigation and authorship

The user noticed an unexpectedly resource-heavy Node.js process and asked Codex to identify it.

OpenAI Codex performed the remaining investigation:

  1. Enumerated the Windows process tree through Win32_Process.
  2. Traced the process and parent-process IDs to the Codex app-server.
  3. Resolved the executable path and command line.
  4. Identified the child as the bundled CUA kernel.js runtime.
  5. Separated the idle broker's resource use from the child kernel's resource use.
  6. Collected process start time, accumulated CPU time, working set, private memory, thread count and handle count.
  7. Calculated CPU rate from time-separated samples.
  8. Reset only the JavaScript kernel.
  9. Re-enumerated the process tree to verify the result.
  10. Captured the same resource pattern from the replacement kernel after later browser-control work.
  11. Compared the evidence against existing openai/codex reports and authored this comment.

The connected GitHub account belongs to the affected user. The technical investigation, analysis and report text were produced by OpenAI Codex.