Codex Desktop on Windows retains/increases memory after opening long tool-heavy thread; memory not released after turns finish

Summary

Codex Desktop on Windows appears to retain and/or continue increasing memory usage after opening a long, tool-heavy thread. The system remains stable when Codex is not running, and also mostly stable when Codex is open but no heavy thread is opened. Opening a large existing conversation causes memory usage to jump and then continue rising; memory is not released after the turn/conversation activity ends.

This looks related to loading/rendering/resuming long thread history with many tool calls / shell outputs / monitoring turns in the Desktop WebView/renderer/app-server path.

Environment

• OS: Windows 11
• Codex Desktop package observed in process path: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
• Workspace: local Windows project
• Machine memory: ~16 GB RAM (TotalVisibleMemorySize about 15.19 GB)
• Affected surface: Codex Desktop app, Windows

Reproduction / A-B observations

1. Reboot machine.
2. Do not start Codex. Observe memory for ~20 minutes.

• Memory remains stable around 40%.

1. Start Codex Desktop but do not open/operate any heavy conversation.

• Memory remains stable around 45%.

1. Open a long existing conversation containing many tool calls, shell outputs, monitoring/waiting turns, and thread-history diagnostics.

• Memory immediately increases to about 52%.
• Without heavy new work, it continues rising to 55%+.

1. Continuing long-running monitoring-style turns eventually pushes memory much higher, up to 90-99%.
2. Ending a turn does not return memory to the previous baseline. Closing/restarting Codex is the only reliable way observed to reclaim the memory.

Concrete diagnostics observed

When memory was healthy after reboot / light Codex usage:

Codex closed: stable around 40%
Codex open but idle: stable around 45%

After opening the long thread:

Memory jumped to ~52%, then kept rising to ~55%+

During higher-pressure cases with active long monitoring/tool turns:

UsedPct: 88-99%
Available memory: dropped as low as ~13 MB in one snapshot
Standby/cache: compressed down near zero in worst cases

Representative snapshot while pressure was high:

UsedPct: 99.1%
AvailableMB: 13
StandbyGB: 0.01
CacheGB: 0.03
NonpagedGB: ~1.92
PagedGB: ~1.19
CommitGB: ~28.78 / 53.19

Another case after restarting and reproducing by opening/using the long thread:

UsedPct: 88.4%
AvailableMB: 1875
StandbyGB: 1.74
CommitGB: 22.67 / 53.19

Process groups were not individually huge, but Codex/WebView/thread history was consistently involved:

Codex: roughly 1.0-1.1 GB Private across multiple processes
msedgewebview2: roughly 0.8-0.9 GB Private across many processes
Long thread token counters: tens of millions on affected histories
Rollout files: several MB with hundreds of tool calls and outputs

The problematic thread pattern includes:

• Long-lived Desktop threads
• Many shell_command calls
• Monitoring/waiting loops (continue monitoring progress, waiting for remote training epochs, reading logs/history repeatedly)
• Many tool outputs, some truncated near ~40 KB
• Thread continuation / summarization chains
• Large accumulated tokens_used values, e.g. affected histories reaching tens of millions of accumulated tokens

Expected behavior

• Opening a long thread may temporarily use extra memory, but memory should stabilize and/or be released after the thread is no longer active.
• Ending a turn should not leave Desktop/WebView/app-server memory permanently elevated.
• Long tool histories should be virtualized / unloaded / garbage-collected so that opening or leaving a thread does not keep increasing system memory pressure.

Actual behavior

• Opening the long thread immediately raises memory usage.
• Staying in the long thread or running additional monitoring-style turns causes memory to continue rising.
• After turns finish, memory is not released back near the pre-open baseline.
• Reopening/continuing long threads amplifies the issue.
• Restarting Codex releases the memory, suggesting retained renderer/session/tool-history state rather than system-wide baseline pressure alone.

Additional notes

I also tested whether this was caused by unrelated system software. After reboot, with Codex closed, memory stayed stable around 40% for ~20 minutes. That makes a pure system-driver leak less likely. GPU overlays / AMD / Lenovo background tools may add pressure, but the cleanest A/B trigger is opening the heavy Codex thread.

This may be a Desktop/WebView memory-retention issue around long conversation history, tool output rendering, stream/log retention, or thread/session state not being released after turns complete.