Long-running Codex sessions lead to whole-PC/laptop lag and freezing on Windows

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.62119

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Long-running Codex Desktop sessions progressively degrade system responsiveness on Windows.

When several threads are allowed to continue working for one or more days, Codex appears to accumulate helper processes, especially codex and node_repl processes. Process count, memory usage, thread count, and OS handles continue growing instead of returning toward baseline after work completes.

The eventual symptoms include:

• Increasing UI latency in Codex.
• Frozen states that last progressively longer.
• Lag affecting the rest of Windows.
• Codex becoming unusable and requiring forced termination.

Terminating Codex immediately releases the accumulated resources and restores responsiveness.

This behavior has occurred on more than one Windows PC, making a machine-specific hardware problem less likely.

<img width="1080" height="1920" alt="Image" src="https://github.com/user-attachments/assets/3778303b-ca8f-4140-85ef-efe898c61bcb" />

What steps can reproduce the bug?

1. Open Codex Desktop on Windows.
2. Create goals in multiple threads.
3. Allow those threads to continue working over an extended period, including normal shell, tool, and REPL activity.
4. Keep Codex running continuously for one or more days.
5. Periodically inspect the number of Codex, codex, node_repl, and command-runner processes.
6. Observe that completed work does not consistently return the helper-process count toward baseline.
7. Continue using Codex as the process and handle counts increase.
8. Observe progressively worse lag and freezing.
9. Terminate Codex and compare resource usage before and after termination.

Using more concurrent threads appears to reproduce the problem faster.

<img width="1080" height="1920" alt="Image" src="https://github.com/user-attachments/assets/0bd6ada4-1a62-40d3-b7cc-c5e3d32a6490" />

What is the expected behavior?

Helper processes and their associated handles, threads, and memory should be reclaimed when their owning task finishes, is cancelled, or becomes inactive.

Long-running Codex sessions should reach a bounded resource baseline rather than accumulating processes indefinitely.

Codex should also:

• Apply limits to retained helper processes and REPL sessions.
• Clean up stale or orphaned helpers automatically.
• Remain responsive during multi-day sessions.
• Provide a graceful runtime reset if internal helpers become unhealthy.
• Avoid degrading the responsiveness of the rest of the operating system.

<img width="1080" height="1920" alt="Image" src="https://github.com/user-attachments/assets/0aa5a928-a839-4dfa-8747-b0f1793fdafb" />

Additional information

I collected one-minute telemetry across a 57-day observation window. The public screenshots contain sanitized aggregate data only.

Observed peaks:

• 77,412 telemetry samples.
• 531 Codex-family processes.
• 263 codex helper processes.
• 259 simultaneous node_repl processes.
• 119,712 OS handles.
• 9,414 threads.
• 12,570 MB private memory.

During one captured severe-lag incident:

Before forced termination:

• 139 Codex-family processes.
• 31,787 handles.
• 2,673 MB private memory.

Within five minutes after termination:

• 4 Codex-family processes.
• 1,833 handles.
• 249 MB private memory.

This suggests a helper-process/session lifecycle defect, handle retention, or missing stale-session cleanup rather than only a conventional JavaScript heap leak.

<img width="1080" height="1920" alt="Image" src="https://github.com/user-attachments/assets/ab9444be-a621-4da6-ba98-655114270471" />