[Windows Desktop] Reopening chats eagerly restores every persisted in-app-browser tab, adding ~3.2 GB RAM

What version of the Codex App are you using?

OpenAI.Codex 26.810.6296.0 (x64)

What subscription do you have?

ChatGPT subscription. The exact tier is omitted because it does not appear relevant to the reproduction.

What platform is your computer?

• Windows 11 Home Single Language
• Version/build: 10.0.26200
• Architecture: x64
• Physical RAM: 15.69 GB

What issue are you seeing?

Reopening an existing chat that contains persisted in-app-browser tabs immediately restores and appears to hydrate every saved page, including inactive tabs that the user does not select.

Opening two existing chats with 13 persisted in-app-browser tabs in total caused a large increase in renderer, app-server, and browser-helper processes and placed a 16 GB Windows system under severe memory pressure.

Observed measurements:

The combined working-set total includes shared pages and the cost of hydrating the chats themselves, so it should not be interpreted as an exact private-memory delta attributable only to browser tabs. However, the sharp increase in renderer/helper process count happens at the same time the persisted browser tab strips are restored.

The memory remained approximately stable during a short sample before reopening the chats. The problem is high eager allocation rather than a continuously increasing leak during that sample.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows.
2. Open a chat with no restored in-app-browser tabs and record the process count/memory.
3. Open an older chat that previously retained several in-app-browser tabs. In this reproduction, the first chat restored approximately 11 tabs.
4. Open a second older chat with persisted browser state. The second chat restored 2 tabs.
5. Do not select or interact with most of the restored tabs.
6. Observe that the tab strips/pages are restored immediately and that ChatGPT renderer, Codex app-server, and browser-helper process counts increase substantially.
7. Observe system memory pressure. On a 15.69 GB machine, physical-memory usage increased from 84.0% to 93.4%.

No active task needs those inactive pages at the time they are restored.

What is the expected behavior?

Persisted browser state should be restored in a resource-bounded way:

• Restore tab metadata/title/URL without eagerly hydrating every inactive page.
• Hydrate only the selected tab on demand.
• Suspend or discard inactive webviews.
• Freeze or release browser webviews belonging to chats that are no longer active.
• Apply a global inactive-tab limit or LRU policy so opening historical chats cannot exhaust memory.

What is the actual behavior?

All persisted browser tabs appear to be restored as live browser surfaces when their chat is opened. Renderer and helper processes accumulate across chats and remain resident, causing severe memory pressure.

Related issue

• #38308 reports embedded-browser tab/process accumulation and crashes during tab finalization. This report is related but distinct: the trigger here is reopening chats with persisted browser state, and the observed failure is eager restoration and memory pressure even without finishing a task or reproducing a crash.

Additional information

Screenshots, chat names, visited domains, session transcripts, and raw logs are intentionally not attached because they contain private browsing and project metadata. Sanitized measurements can be expanded if maintainers need a specific diagnostic.

Start by tracing persisted browser-state restoration when an existing chat is reopened, across the Codex Desktop renderer, app-server, and browser-helper processes. Compare how inactive tabs are hydrated and retained, then verify that only the selected tab is hydrated and that inactive webviews are bounded or released without restoring chats causing severe memory pressure.