[Windows Desktop 26.803.5235.0] Long-running session retains ~2.35 GB, mostly in two ChatGPT.exe renderer processes

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

OpenAI.Codex 26.803.5235.0 (Microsoft Store/MSIX)

What subscription do you have?

Not disclosed; this appears unrelated to subscription tier.

What platform is your computer?

• Windows 11 Pro Insider Preview, x64
• OS build 26220
• 32 GB physical RAM

What issue are you seeing?

After a long-running Codex Desktop session (approximately nine hours), the complete desktop process tree retained about 2.35 GB of private memory across 19 processes.

The allocation was concentrated in the desktop host/renderer processes rather than in the Codex app-server or a large MCP/helper process fan-out:

The two largest desktop host/renderer processes retained approximately:

• 917 MB private memory / 829 MB working set
• 489 MB private memory / 456 MB working set

By comparison, the codex.exe app-server itself retained about 96 MB private memory. Only two node_repl.exe helpers were present (about 3 MB private memory each), and there was no large node.exe, git.exe, taskkill.exe, or conhost.exe accumulation.

A 15-second sample taken during ordinary active use remained nearly flat:

This sample does not show an actively runaway leak. The concern is the high retained renderer baseline after extended use and the absence of a way to identify or unload the renderer state responsible for it.

This appears different from #37672, where the same app version starts hundreds of Node/code-mode helpers and consumes roughly 10–13 GB. The helper fan-out from that issue is not present here. It may be closer to the renderer retention/spike patterns in #34305 and the long-thread renderer-state behavior in #21134.

What steps can reproduce the bug?

1. Launch Codex Desktop on Windows.
2. Use local Codex tasks normally for several hours, including shell/tool calls and switching between tasks.
3. Without restarting the app, enumerate the complete process tree rooted at the desktop host.
4. Sum PrivateMemorySize64 and WorkingSet64.
5. Observe that approximately 2 GB is retained by the ChatGPT.exe host/renderer group, while the Codex app-server and helper tree remain comparatively small.

I have not yet performed a clean-restart A/B baseline because restarting would interrupt the active diagnostic session.

What is the expected behavior?

• Inactive task/renderer state should be compacted or unloaded after extended use.
• Renderer memory should return to a bounded baseline when task views are no longer active.
• The app should expose enough diagnostics to map a high-memory renderer to its role or owning task without requiring access to private conversation data.
• A typical long-running session should not retain multiple renderer processes approaching 0.5–1 GB each unless that memory is actively required.

Additional information

Privacy precautions used for this report:

• No command lines were collected.
• No user name, host name, workspace/repository path, conversation ID, prompt, tool output, account identifier, or log content is included.
• No raw application logs, SQLite databases, session files, or memory dumps are attached.
• Process IDs were intentionally omitted because they add no reproduction value.

The measurements were collected with read-only Windows process APIs using only process name, parent/child relationship, working set, private bytes, thread count, start time, OS build, total RAM, and package version.

No source files, tests, or entry points are named. Start by reproducing the long-running Windows session and collect the clean-restart A/B baseline, then identify which renderer state retains memory; done means inactive renderer memory returns to a bounded baseline or the responsible state can be diagnosed.