Windows: severe slowdown after extended use with high memory usage in cua_node and codex background processes

Summary

After using the Codex desktop app for a while, the UI becomes severely slow or unresponsive. During an affected session, a Codex-bundled Node worker and the codex background process had very high private committed memory usage.

Environment

• App package: OpenAI.Codex 26.901.6511.0
• OS: Windows 11 Home, build 26200
• Windows display language: Japanese
• Installed RAM: 32 GB; approximately 8 GB is intentionally reserved for the integrated GPU
• Total physical memory available to Windows: approximately 23.62 GiB
• An external GPU dock is also connected

Observations before exiting

One process sample recorded:

• node.exe (PID 31564): Private Bytes 15.22 GiB; Working Set 3.59 GiB.
• This executable belonged to the Codex runtimes/cua_node directory. Its parent was node_repl.exe, and it was running trusted-worker.js.
• codex.exe (PID 18624): Private Bytes 10.33 GiB; Working Set 5.39 GiB.

A separate system sample recorded:

• Committed memory: 59.87 GiB out of a 66.63 GiB commit limit.
• Available physical memory: approximately 1 GiB.
• Resource Monitor showed hundreds of hard faults per second for the Node process at sampled moments.

Memory usage fluctuated between samples; continuous monotonic growth has not been established. Private Bytes figures above are private committed memory, not physical RAM usage or V8 heap measurements.

Exit/restart comparison

1. I exited the application normally.
2. Both affected processes disappeared automatically. No processes were manually killed and no memory-cleaning utility was used.
3. After reopening the app, a new sample showed codex.exe at approximately 116 MiB of Private Bytes, and system available physical memory at approximately 10.42 GiB.
4. The Node processes present in that post-restart sample each had approximately 20–75 MiB of Private Bytes. They may not have been running the same workload as the original worker, so this is not a controlled same-workload comparison.

Expected behavior

Memory consumption should remain manageable during extended use, without severe UI slowdown or unresponsiveness from excessive memory pressure.

Investigation requested

Please investigate memory retention, cache growth, or a possible leak in long-running cua_node/node_repl workers and the codex background process. The exact triggering sequence is not yet isolated. These observations do not establish a V8 garbage-collector defect or prove a memory leak.

Before/after Process Explorer and Resource Monitor screenshots were collected locally and can be provided if needed.

Start by examining the long-running cua_node/node_repl workers running trusted-worker.js and the codex background process on Windows. Reproduce an extended-use session and compare Private Bytes, Working Set, commit usage, and hard faults before and after restart; done requires an isolated trigger and evidence identifying or ruling out memory retention, cache growth, or a leak.