Skip to content

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

Open

Description

@whitelinemanon

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.
  3. Restart Codex Desktop.
  4. Open the mini/popout windows one by one.
  5. 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:

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

Activity

  1. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 1, 2026
  2. whitelinemanon commented on May 1, 2026

    @whitelinemanon
    Author

    Thanks. I reviewed these related issues before filing.

    This report may overlap with them, especially #19936 and #20269, but I am keeping it separate because it includes a staged local comparison between text-heavy, search-heavy, and image-heavy threads when opening mini/popout windows.

    The main additional signal here is that the worst freezes correlated more strongly with image-generation-heavy history than with session length alone. I also attached sanitized per-window freeze samples and process samples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancesessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions