Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop freezes when opening mini/popout windows; image-heavy histories are much worse than long text-heavy sessions [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20544•Fetched 2026-05-01 05:41:58
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
0
Author
whitelinemanonwhitelinemanon
Participants
github-actions[bot]github-actions[bot]whitelinemanonwhitelinemanon
Timeline (top)
labeled ×4commented ×2closed ×1cross-referenced ×1

Root Cause

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.

Code Example

%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
RAW_BUFFERClick to expand / collapse

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:

StageWindow labelModelSession profileSearch usageImage usageOpen durationSample rowsUnique paths
1999GPT-5.5longest sessionmedium2 images21.7s853140
2997GPT-5.3 Codexmedium sessionhigh2 images17.9s692148
3996GPT-5.4medium-long sessionmedium10+ images124.7s4591166
4994GPT-5.3 Codex Sparkshort sessionhigh0 images67.4s2900173
5992GPT-5.5short sessionnone40+ images313.7s12848186

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

extent analysis

TL;DR

The issue can be mitigated by optimizing the handling of image-heavy sessions and improving lazy-loading or incremental hydration of expensive preview/render states.

Guidance

  • Review the attached sanitized logs and sampling data to better understand the freeze events and system resource utilization patterns.
  • Investigate optimizing the restoration of session/thread states, particularly for image-heavy sessions, to reduce the load on the UI thread.
  • Consider implementing more efficient caching or lazy-loading mechanisms for image previews and render states to minimize the impact on the main UI thread.
  • Analyze the provided reproduction pattern and staged test results to identify potential bottlenecks and areas for improvement.

Example

No specific code snippet can be provided without more context, but optimizing the handling of image-heavy sessions might involve techniques such as:

# Pseudo-code example of lazy-loading image previews
def load_image_preview(image_id):
    # Check if image preview is already cached
    if image_id in cache:
        return cache[image_id]
    # Load image preview in a background thread
    preview = load_image_preview_async(image_id)
    # Cache the loaded preview
    cache[image_id] = preview
    return preview

Notes

The issue seems related to existing reports of performance collapses with large local conversation histories, and addressing this might require a combination of optimizations and potentially changes to how sessions are managed and restored.

Recommendation

Apply workaround: Optimize the handling of image-heavy sessions and improve lazy-loading or incremental hydration of expensive preview/render states, as this appears to be a key factor in the freezes experienced.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING