[Windows] CUA node_repl workers remain after Code Mode task completion and correlate with system-wide UI stalls

Summary

On Windows, the Codex desktop app can become severely sluggish during and after a long Code Mode task that creates and repeatedly validates an interactive HTML presentation. Mouse movement and window interaction then stutter across the system, even though CPU is not saturated, disk I/O is low, and substantial physical memory remains available.

Completing the task does not reliably recover the machine. Fully exiting the Codex desktop app immediately restores normal responsiveness because it terminates the shared app-server and Code Mode runtime process tree.

Environment

• OS: Windows 11 x64
• Desktop app package: OpenAI.Codex_26.810.6296.0_x64
• CUA Node runtime: cua-node 0.0.8
• Node version: 24.19.0
• Local app-server command includes: features.code_mode_host=true app-server --analytics-default-enabled

Reproduction

1. Start the Windows Codex desktop app.
2. Run a task that creates or iterates on a rich interactive HTML presentation.
3. Ask Codex to render/inspect the page and validate desktop/mobile layout and interactions using browser or Playwright-based checks.
4. Repeat several iterations, including interaction and responsive-layout validation.
5. After the task reports completion, continue using the desktop app and other Windows applications.
6. Observe severe system-wide UI and mouse stutter. Fully exit the desktop app and observe that responsiveness returns.

Observed process behavior

• codex.exe runs the shared local app-server and owns codex-code-mode-host.exe.
• node_repl.exe processes from the bundled cua_node runtime appear as direct children of the same app-server process.
• The node_repl.exe count reached 37 during the affected session.
• After the HTML task became idle/completed, 21 node_repl.exe processes plus codex-code-mode-host.exe were still present.
• The main desktop process was approximately 1 GB working set; large renderer processes were approximately 0.6 GB and 0.2 GB.
• The OS process command line does not expose a thread/task ID, so I cannot assign every retained child to one conversation. Some later child processes were also created while collecting diagnostics. The correlation is nevertheless strongest around the repeated HTML/browser-validation task and the shared runtime lifecycle.

Performance evidence during the lag window

• Available memory was approximately 28--31 GB, so this did not look like simple physical-memory exhaustion.
• Hard page reads and writes were near zero or very low; disk queue and latency were low.
• Windows soft/transition-fault activity became extremely high, approximately 430k--470k events/sec in the worst observed samples.
• Memory Compression was approximately 3.8--3.95 GB.
• System CPU was only about 20--48% and was not saturated, but processor-queue spikes were observed.
• No Application Error or Application Hang event was recorded for the session.
• Fully exiting the desktop app terminated the shared runtime tree and immediately removed the stutter.

Expected behavior

When a Code Mode task reaches a terminal state, task-specific browser/Computer Use resources should be terminated and reaped, or a bounded shared worker pool should be reused. Multiple Codex conversations should not leave an accumulating set of runtime workers that can make the Windows desktop unresponsive.

The desktop UI should remain responsive after a task completes without requiring a full application restart.

Requested investigation

Please instrument the CUA/Code Mode spawn and cleanup lifecycle with a task/run ID, spawned PID, parent PID, terminal reason, terminate result, and wait/reap result. In particular, verify whether node_repl workers are intentionally shared, whether they are expected to survive a completed task, and whether the number of workers is bounded and reused rather than recreated per task.

If workers are task-owned, please add a regression test covering completion, cancellation, error, tool timeout, and app-server disconnect paths. If they are intentionally shared, please verify that completed tasks release their browser/runtime state and that the shared pool cannot grow without bound.

Related issues

• #35582 -- Desktop retains completed CUA node_repl workers on macOS.
• #38093 -- Code Mode can report a terminal result while child work is still alive.
• #38713 -- Windows desktop main-process thrash after opening an already-running app; related symptom, different trigger.

No source files or tests are named. Start by tracing the app-server and Code Mode CUA spawn and cleanup lifecycle, including the bundled cua_node runtime; instrument task/run IDs, PIDs, terminal reasons, and terminate and reap results. Done means terminal, cancellation, error, timeout, and disconnect paths clean up workers or enforce a bounded reusable pool, with regression coverage.