[Windows Desktop] Progressive memory growth during an automated SSH research workflow makes Windows unusable after 10+ hours

What version of the Codex App are you using?

Codex Desktop 26.803.5235.0

What subscription do you have?

ChatGPT Pro (US$200/month)

What platform is your computer?

• OS: Windows 11 Pro 25H2, Build 26200.8973, x64
• CPU: Intel Core Ultra 9 185H
• RAM: 32 GB
• Integrated GPU: Intel Arc Graphics, driver 32.0.101.8132
• Discrete GPU: NVIDIA GeForce RTX 4070 Laptop GPU, driver 32.0.16.1074

What issue are you seeing?

I run an automated scientific research experiment workflow. The server administrators do not permit installing Codex on the server, so Codex Desktop runs only on my local Windows computer. No Codex component is installed on the remote server; all communication between local Codex and the server is performed over SSH.

I maintain a local working directory as a staging area for planning documents, experimental code, and related documentation. Based on the planning documents, Codex designs and builds the code required for the experiments, updates files in the local staging directory, and then uses SSH to synchronize or update files on the server, launch experiment commands, monitor execution, inspect results, modify the implementation, and continue iterating.

This is primarily an automated, long-running workflow rather than a single interactive SSH session. It continuously produces local file operations, SSH tool calls, terminal output, monitoring output, and persistent task history.

During this workflow, Codex memory usage grows gradually and is not adequately reclaimed. The Codex UI becomes progressively slower, followed by severe system-wide memory pressure. Closing unrelated applications temporarily creates free memory, but Codex gradually consumes the available headroom again.

Abnormal memory growth and UI latency usually become noticeable after several hours. After more than ten hours of continuous operation, Codex and Windows can become so unresponsive that normal mouse movement is no longer possible.

Read-only process measurements

Measurements collected while the problem was occurring showed:

• The combined Codex/ChatGPT process tree retained approximately 8.9 GB of private committed memory.
• The largest ChatGPT.exe renderer retained approximately 5.7 GB of private memory and 2.1 GB of working set.
• The codex.exe app-server retained approximately 2.0 GB of private memory.
• The GPU process retained approximately 0.48 GB of private memory. A short GPU sample averaged about 23% utilization and peaked around 30%.
• Node helper processes used approximately 26 MB in total.
• SSH client processes used approximately 29 MB in total. SSH itself was therefore not the direct multi-gigabyte memory consumer.
• During a 15-second process sample, the large renderer remained near its 5.7 GB retained baseline. The app-server increased by approximately 8 MB.
• Windows reported the processes as responding even though the Codex interface was noticeably delayed.
• No git.exe process was captured during 206 high-frequency polls over 15 seconds. There was no evidence of a repeating git status or git ls-files --others loop during the sample.

Persistent storage measurements

• Persistent local session-history files occupied approximately 9.2 GB on disk.
• Multiple individual session files exceeded 1 GB.
• One active session file was approximately 0.5 GB and was still growing.
• The local logs SQLite database was approximately 0.85 GB.
• Its WAL was approximately 6 MB and remained stable during a 15-second sample.
• Windows Error Reporting recorded a RADAR_PRE_LEAK_64 event for codex.exe.

The session-history files and SQLite database are disk usage rather than RAM usage. However, their size may explain the app-server and renderer memory retention if large histories are repeatedly loaded, deserialized, copied, indexed, rendered, or retained after context compaction.

System-level memory measurements

A simultaneous Windows memory snapshot showed:

• Approximately 59.3 GiB of committed memory in use out of a 71.1 GiB commit limit.
• Approximately 5.5 GiB of physical memory remaining.
• Approximately 17.4 GiB of paged kernel pool.
• Approximately 3.2 GiB of nonpaged kernel pool.
• The dominant pool tag, Vi54, accounted for approximately 13.2 GB and continued growing slowly.
• Windows Driver Verifier was disabled and no drivers were being verified.

The Codex process tree directly accounts for approximately 9 GB of private committed memory. The unusually large Windows kernel pools account for a substantial part of the remaining system-wide pressure.

Ownership of the kernel allocation has not been established, so I am not claiming that Codex directly owns it. However, it occurs alongside the long-running Codex workload and should be investigated as a possible secondary Chromium, GPU, networking, SSH, or virtualization-related allocation path.

Technical assessment

The symptoms suggest that large task histories or tool outputs may be retained at multiple layers:

1. persistent rollout/session storage;
2. deserialized app-server history;
3. serialized data transferred between the app-server and renderer;
4. renderer-side terminal and tool-output objects; and
5. possible secondary allocations in Windows graphics, networking, or virtualization paths.

Context compaction appears to reduce the model context but does not appear to place an effective bound on persisted history, renderer state, or app-server memory associated with the active task.

This resembles the eager full-rollout loading reported in #25215. That report describes paths that read an entire rollout before returning bounded results. This case suggests that the same class of behavior may also affect an active task, not only the resume or task-list path.

An actionable investigation would be to check rollout loading and task-history paths for:

• whole-file reads such as read_to_string;
• collection of the complete history into Vec<RolloutItem>;
• repeated full-history loading after context compaction;
• duplicate serialization between the app-server and renderer;
• retention of completed terminal/tool output in renderer state; and
• task-list or sidebar refreshes that hydrate more history than the UI requires.

What steps can reproduce the bug?

1. Run Codex Desktop locally on a Windows machine with 32 GB of RAM.
2. Create a local working directory containing experiment planning documents, code, and related documentation.
3. Use Codex to read the planning documents and automatically construct the required experimental code.
4. Have Codex communicate with a remote server exclusively through SSH. No Codex component is installed on the server.
5. Repeatedly use SSH to update server files, launch experiments, monitor running commands, retrieve results, and iterate on the code.
6. Allow the task to undergo context compaction while continuing to use it.
7. Continue the automated workflow for several hours without restarting Codex Desktop.
8. Switch between tasks or continue using the same task.
9. Observe the growth of persistent session-history files and retained renderer/app-server memory.
10. Close unrelated applications to temporarily free memory.
11. Continue using Codex and observe that the newly available memory is gradually consumed again.
12. After several hours, observe abnormal memory growth and increasing UI latency.
13. Continue the workflow for more than ten hours.
14. Observe severe system-wide responsiveness problems, eventually including heavily delayed or unusable mouse movement.

The reproduction does not require a Git polling loop, a large Node process, or high direct memory consumption by the SSH client.

What is the expected behavior?

• Completed terminal and tool output should not remain fully materialized in renderer memory.
• Large output should be virtualized, paged, truncated, or moved to bounded backing storage.
• Active-task, resume, list, and compaction paths should use streaming or indexed access instead of loading an entire multi-gigabyte history into memory.
• Context compaction should create a durable storage checkpoint so that pre-compaction records do not need to be repeatedly hydrated.
• Large session histories should be safely segmented or rotated without losing user work.
• Renderer and app-server memory should be released when task data becomes inactive or is no longer visible.
• One large task should not degrade unrelated tasks or the entire desktop application.
• A single oversized or corrupted task history should be isolated from the sidebar, task list, and other active tasks.
• Local log retention and SQLite growth should have documented and configurable bounds.
• Codex should warn before a task reaches a history size known to cause unsafe memory use.
• Diagnostic counters should distinguish stored history size, deserialized app-server memory, renderer memory, GPU memory, and terminal-output retention.
• Completed SSH commands and monitoring operations should not cause unbounded retained history or renderer objects.
• The interaction between long-running Codex activity and abnormal Windows kernel-pool growth should be investigated.

Please investigate both:

1. app-server rollout/history loading, deserialization, copying, indexing, and retention; and
2. renderer-side retention of terminal/tool-output objects after command completion, context compaction, or task switching.

Additional information

Potentially related reports:

• #25215 — Long threads become unrecoverable when rollout JSONL files grow beyond resume/list limits
• #37811 — Long-running Windows session retains gigabytes in renderer processes
• #35963 — Windows desktop memory-leak and hang events
• #29700 — Windows system/kernel memory growth
• #24510 — High CPU from unbounded active-thread metadata and local history/list processing

This report combines four symptoms that may share a common lifecycle problem:

• multi-gigabyte persistent task history;
• high app-server memory;
• high renderer memory; and
• system-level memory pressure while the automated task remains active.