Repository navigation
Large active session causes global freezes with no UI attribution #21948
Description
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:
- Use Codex Desktop with a browser-use-heavy session that accumulates many screenshots, DOM/snapshot payloads, and embedded data:image / base64 artifacts.
- Let that session remain active/unarchived in the left panel.
- Continue using Codex, including other sessions.
- Codex Desktop begins having repeated small hangs/freezes globally.
- Archive the browser-use-heavy session.
- Continue using Codex.
- The freezes stop.
How I identified it:
- Windows logs showed Codex/OpenAI app hang reports.
- A local log/database cleanup reduced accumulated local log storage, but smaller freezes continued.
- The freezes stopped only after one browser-use-heavy session was archived.
- I sorted active and archived session files by size.
- The recently archived session stood out at about 173 MB.
- Inspecting the JSONL showed about 163 MB concentrated in only 20 records over 1 MB each.
- 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.
Activity
github-actions commentedon May 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
cnjimmyshao commentedon May 9, 2026
This looks likely related to #18629, especially the part about embedded
data:image/ base64 artifacts in active session JSONL causing Desktop-wide responsiveness issues.I added a more code-path-oriented storage-layer analysis in #18629 here:
#18629 (comment)
The overlap, as I understand it, is that UI pagination/lazy hydration can reduce the thread-open symptoms, but image-heavy rollouts can still keep growing if replayable JSONL stores large image blobs inline. A durable fix probably needs to prevent new rollout records from persisting those blobs inline in the first place, while keeping old histories readable.
psremilio commentedon May 13, 2026
Same issue here on Windows.
Codex Desktop 26.506.3741.0 becomes repeatedly unresponsive in longer chats: the UI freezes, briefly recovers, then freezes again until Windows shows the wait/close-app prompt. Windows Error Reporting logs
AppHangTransientforCodex.exe.This correlates strongly with large local state on my machine:
%USERPROFILE%\.codex: about 3.23 GBlogs_2.sqlite+ WAL: about 619 MBSystem resources are not generally exhausted, so this looks like the desktop app is doing expensive session/log loading, rendering, indexing, or background processing against large local state.
ericlee041769-hash commentedon Jul 15, 2026
I can reproduce the same bug on a much newer Windows build/app package, with large multi-agent sessions rather than browser screenshots.
Environment:
User-visible failure:
(code=3221226505, signal=null)memory allocation of 236144 bytes failedmemory allocation of 32768 bytes failed.Local profile evidence before cleanup:
~/.codex/sessions: 4.155 GB.state_5.sqlitereportedtokens_used=1,434,782,369for the active parent and1,227,782,546for one completed subagent.thread_spawn_edgesstill had 17openchildren for the active parent, 54 for the previous duplicate parent, and 46 for an older duplicate parent. The child work had already finished.No Codex thread found. There is no supported UI/API cleanup path for these hidden oversized child sessions.The log sink amplified the problem:
logs_2.sqlite: 1,339,052,032 bytes after only 10 days.RUST_LOG=warn.codex_api::sse::responses(106,891 rows),codex_core::stream_events_utils(49,629), andcodex_mcp::connection_manager(90,452).VACUUMreduced the DB to 210,612,224 bytes.Mitigations performed:
This still looks like an app scalability/lifecycle bug, not merely weak hardware:
open;Requested fixes:
This appears closely related to #20213, #21134, and the meta issue #25779, but #21948 is the closest Windows user-visible repro.