Codex Desktop freezes when opening mini/popout windows; image-heavy histories are much worse than long text-heavy sessions

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

OpenAI.Codex 26.429.2026.0 PackageFullName: OpenAI.Codex_26.429.2026.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop can freeze when opening or resuming mini/popout windows. During the freeze, the entire Codex UI becomes unresponsive, including the top menu bar. This is not just delayed model output or a slow network response; the local desktop UI itself stops responding.

The severity does not appear to be explained by session length alone. In my local comparison, my longest text-heavy session is not the worst case. Instead, image-heavy or image-generation-heavy sessions freeze much more severely.

Clearing the Codex app cache did not resolve the issue.

Important note about the attached logs:

The most complete local sampling logs were captured shortly before updating, when sampled paths still showed OpenAI.Codex_26.422.8496.0_x64.
After updating to OpenAI.Codex 26.429.2026.0, the same general mini-window freeze behavior still occurs.
I am attaching the pre-update logs because they are the cleanest complete capture I currently have. I can collect a fresh post-update capture if maintainers need one.

What steps can reproduce the bug?

This is my current reproduction pattern:

1. Use Codex Desktop on Windows with multiple long-running threads and mini/popout windows.
2. Have several threads with different histories:

• one very long text-heavy thread,
• one or more image-generation-heavy threads,
• one search-heavy but image-light thread.

1. Restart Codex Desktop.
2. Open the mini/popout windows one by one.
3. Observe that some windows open relatively quickly, while image-heavy threads can freeze the whole Codex UI for much longer.

In one staged test, I opened five mini windows in sequence:

| Stage | Window label | Model | Session profile | Search usage | Image usage | Open duration | Sample rows | Unique paths |
|---:|---|---|---|---|---|---:|---:|---:|
| 1 | 999 | GPT-5.5 | longest session | medium | 2 images | 21.7s | 853 | 140 |
| 2 | 997 | GPT-5.3 Codex | medium session | high | 2 images | 17.9s | 692 | 148 |
| 3 | 996 | GPT-5.4 | medium-long session | medium | 10+ images | 124.7s | 4591 | 166 |
| 4 | 994 | GPT-5.3 Codex Spark | short session | high | 0 images | 67.4s | 2900 | 173 |
| 5 | 992 | GPT-5.5 | short session | none | 40+ images | 313.7s | 12848 | 186 |

The worst case was not the longest session. The worst case was the image-heavy thread.

What is the expected behavior?

Opening or resuming a mini/popout window should not block the whole Codex Desktop UI.

If a thread has a large history, image-generation history, or expensive preview/render state, that work should be lazy-loaded, incrementally hydrated, or isolated from the main UI thread.

Additional information

Local sampling data

I collected local samples during the staged mini-window opening test.

The cleaned attachment set includes:

• 999_official_repro_summary.csv
• compact staged-window summary matching the table above.
• 999_official_freeze_events_20260430_144153_sanitized.txt
• window responsiveness event log.
• 999_official_freeze_samples_20260430_144153_sanitized.csv
• per-window responsiveness samples with private window titles replaced by broad categories such as Codex, Image Viewer, Windows File Explorer, and Chrome.
• 999_official_process_samples_20260430_144153_sanitized.csv
• process-level CPU / IO / memory / thread / handle samples.
• 999_official_title_sanitization_map.md
• explains the title sanitization rules used before public upload.

During heavier stages, separate local handle sampling repeatedly showed paths such as:

%USERPROFILE%\.codex\state_5.sqlite
%USERPROFILE%\.codex\state_5.sqlite-wal
%USERPROFILE%\.codex\logs_2.sqlite
%USERPROFILE%\.codex\logs_2.sqlite-wal
Codex app resources such as resources.pak, v8_context_snapshot.bin, locale packs
GPU/WebView cache files
IPC / named-pipe paths

This makes me suspect that opening mini/popout windows may trigger expensive session/thread restoration, renderer hydration, image preview/render state handling, or repeated local state/cache access.

Why this may be related to existing reports

This seems related to the same problem family as:

• #20269: oversized rollout JSONL causing Codex Desktop to freeze on launch/resume
• #18693: desktop performance collapse with very large local conversation histories
• #18849: large Codex sessions causing desktop freeze on open

My case may add a more specific signal: image-heavy / image-generation-heavy histories appear much worse than longer text-heavy histories.

Privacy note

I am attaching sanitized summaries first. I am not uploading raw .codex databases, session files, auth files, screenshots, or unsanitized personal logs.

999_official_freeze_events_20260430_144153_sanitized.txt
999_official_freeze_samples_20260430_144153_sanitized.csv
999_official_process_samples_20260430_144153_sanitized.csv
999_official_repro_summary.csv
999_official_title_sanitization_map.md

Attached sanitized files:

• 999_official_repro_summary.csv
• 999_official_freeze_events_20260430_144153_sanitized.txt
• 999_official_freeze_samples_20260430_144153_sanitized.csv
• 999_official_process_samples_20260430_144153_sanitized.csv
• 999_official_title_sanitization_map.md