[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:

| Process group | Process count | Approx. private memory |
| --- | ---: | ---: |
| Desktop host/renderers (ChatGPT.exe) | 10 | 2.05 GB |
| Codex app-server and descendants | 7 | 255 MB |
| Other small active tool helpers in the same tree | 2 | < 10 MB |
| Complete tree | 19 | 2.32–2.36 GB |

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:

| Time offset | Complete-tree private memory | Working set |
| --- | ---: | ---: |
| 0 s | 2359.7 MB | 2319.7 MB |
| 5 s | 2340.3 MB | 2335.8 MB |
| 10 s | 2347.2 MB | 2342.3 MB |
| 15 s | 2351.8 MB | 2342.2 MB |

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.