Large active session causes global freezes with no UI attribution

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

25.506.31421

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop became intermittently unresponsive during normal use. The freezes affected the whole app, even when I was not engaging with the session that ultimately appeared to be responsible.

The issue stopped after I archived a single session. That session was browser-use heavy and contained many screenshots, DOM/snapshot payloads, and large embedded image/base64 artifacts. The session was about 173 MB.

The main issue is that Codex gave no indication that a particular session was problematic. Nothing in the UI pointed to session size, browser artifacts, background processing, or archiving as a possible fix. From the user’s perspective, there was no intuitive reason to suspect that one session in the left panel could degrade global app performance while working elsewhere.

What steps can reproduce the bug?

I do not have a minimal code snippet, but the observed repro pattern is:

1. Use Codex Desktop with a browser-use-heavy session that accumulates many screenshots, DOM/snapshot payloads, and embedded data:image / base64 artifacts.
2. Let that session remain active/unarchived in the left panel.
3. Continue using Codex, including other sessions.
4. Codex Desktop begins having repeated small hangs/freezes globally.
5. Archive the browser-use-heavy session.
6. Continue using Codex.
7. The freezes stop.

How I identified it:

1. Windows logs showed Codex/OpenAI app hang reports.
2. A local log/database cleanup reduced accumulated local log storage, but smaller freezes continued.
3. The freezes stopped only after one browser-use-heavy session was archived.
4. I sorted active and archived session files by size.
5. The recently archived session stood out at about 173 MB.
6. Inspecting the JSONL showed about 163 MB concentrated in only 20 records over 1 MB each.
7. The largest records were about 52 MB and 32 MB, both compaction records containing browser-heavy history.

What is the expected behavior?

One inactive or not-currently-engaged-with session should not degrade responsiveness across the whole Codex Desktop app without attribution.

Codex should either avoid expensive background processing of oversized inactive sessions or clearly identify the problem. Expected behavior would include one or more of:

• warning when a session becomes unusually large,
• warning when a session contains large embedded browser artifacts,
• showing session size in the UI,
• identifying which session is being processed when the app hangs or becomes busy,
• throttling or excluding oversized inactive sessions from expensive background work,
• deduplicating or externalizing large browser screenshots/base64/DOM artifacts,
• recommending archive/cleanup when a session is likely affecting performance.

Additional information

System details, to help rule out weak hardware:

• Dell laptop, Dell Pro Max 16 Premium MA16250
• System SKU / part number: 0D33
• Windows 11 Pro, 64-bit, build 26200
• CPU: Intel Core Ultra 9 285H
• RAM: about 64 GB
• Disk: 2 TB NVMe SSD, healthy, about 604 GB free at capture time
• Display: 3840 x 2400 at 120 Hz
• Active graphics path should be treated as Intel Arc Pro 140T GPU
• NVIDIA RTX PRO 3000 Blackwell Generation Laptop GPU was present but disabled in Device Manager with Code 22
• Codex app package observed: 26.506.3741.0

Windows evidence captured:

• 5,072 filtered Application events
• 2,303 filtered System events
• 6 copied Windows Error Reporting reports matching OpenAI app hangs
• The copied WER reports included Codex desktop app hang reports.