›_ Codex Issues
Codex Issues / #37550

macOS desktop: primary window stuck on loading screen while tasks continue; New Window recovers but browser state is lost

Open 💬 5 comments Opened Aug 8, 2026 by it-yusha
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

ChatGPT/Codex Desktop 26.803.41515 (CFBundleVersion 6321)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5.2 (build 25F84)

What issue are you seeing?

The primary ChatGPT/Codex desktop window intermittently becomes stuck on the blank initial loading screen (gray/white background with the OpenAI logo). This occurred several times on August 8, 2026.

The application process itself does not exit, and active Codex tasks continue running in the background. Selecting File > New Window opens a functioning window where the task and its in-progress output remain available. However, the original window does not recover, and the in-app browser tabs/state from that window are not restored in the new window.

A screenshot was captured at approximately 16:09 JST. Local desktop logs immediately before and during the occurrence showed repeated primary-renderer errors:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
rendererWebContentsId=1
rendererWindowAppearance=primary
rendererWindowFocused=true
rendererWindowVisible=true

The errors appeared repeatedly from approximately 07:06:49 through 07:08:26 UTC. During the same period, AppServer responses continued successfully with errorCode=null and targetDestroyed=false, including thread reads, turn updates, and browser-session lifecycle events.

No new macOS ChatGPT/Codex crash diagnostic report was generated for these occurrences.

The logs also contain failures restoring in-app browser navigation history with ERR_FAILED. Raw logs are not attached publicly because they contain conversation and local environment metadata.

What steps can reproduce the bug?

The issue is intermittent, but the observed sequence is:

  1. Run the macOS ChatGPT/Codex desktop app with several Codex tasks active and in-app browser tabs open.
  2. Switch between tasks and use the in-app browser during normal work.
  3. The primary window occasionally clears and becomes stuck indefinitely on the initial loading screen.
  4. Wait; the original window does not recover.
  5. Choose File > New Window.
  6. The newly created window loads correctly and shows that the active Codex task continued running.
  7. The in-app browser tabs/state from the original window are absent.

Feedback with the current session diagnostics was uploaded under:

Feedback ID: 019f7b28-e4fe-7fb1-858a-95fd1dda8719

What is the expected behavior?

The primary renderer should remain usable while tasks and in-app browser sessions are active.

If the renderer must reload, it should recover automatically without remaining on the loading screen. Active task state and in-app browser tabs/navigation history should be preserved or restored in a replacement window.

Additional information

This appears to be a primary-window renderer/UI-state failure rather than a full application or app-server crash:

  • Active Codex work continues in the background.
  • A fresh window can reconnect to the running task.
  • The original window alone remains unusable.
  • No corresponding macOS crash report was created.
  • Repeated ResizeObserver errors correlate with the failure window.

Possibly related, but not exact duplicates:

  • #33996 — same ResizeObserver error and UI freezing, but on Windows
  • #34255 — macOS renderer/composer state desynchronization after switching chats
  • #34890 — macOS window blanks/reloads during heavy multi-thread use, but that report includes confirmed renderer OOM crashes

This report differs because the app remains alive, the task continues, no OOM/crash evidence was found, and New Window is a partial recovery that loses the in-app browser state.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 20 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37541

Powered by Codex Action

juncoflockleader · 17 days ago

I reproduced this exact failure on Codex Desktop 26.803.41515 (build 6321), macOS arm64.

The desktop window became stuck indefinitely on the logo/loading screen, while active tasks continued normally and remained controllable remotely from my phone. There was no macOS crash report, system memory pressure, or evidence of a backend failure.

Additional diagnostics strongly correlate the renderer failure with unbounded local task history:

  • 2,341 visible/unarchived tasks using approximately 77 GB
  • One active, image/tool-heavy transcript exceeded 6.1 GB
  • Other active transcripts were approximately 225–227 MB
  • thread/turns/list for the 6.1 GB task took roughly 13.5–14.2 seconds, versus approximately 0.6 seconds for the smaller tasks
  • Desktop APIs for listing or navigating tasks could block for over 60 seconds
  • Logs included:
  • [persisted-atom] host did not respond to sync request
  • Conversation state not found
  • Received turn/started for unknown conversation
  • Received turn/completed for unknown conversation
  • repeated ResizeObserver loop completed with undelivered notifications

A sample of the oversized transcript showed most growth came from inline image-generation records and large function/tool outputs, including individual records exceeding 20 MB.

Recovery evidence:

  • Archived completed task trees using the supported thread/archive API
  • Visible tasks decreased from 2,341 to 706
  • Active session storage decreased from approximately 77 GB to 9.9 GB; archived data remained recoverable
  • Unpinned the 6.1 GB task without interrupting it
  • The task list then loaded in approximately 1.1 seconds and navigation recovered
  • SQLite integrity check returned ok
  • Running background tasks were not interrupted

This appears to be renderer/state-hydration overload rather than an app-server or job failure. One oversized task should not prevent the primary window from loading or navigating elsewhere. Lazy/byte-bounded transcript hydration and externalizing large image/tool payloads would likely prevent this failure mode.

Raw transcripts and logs are not attached publicly because they contain conversation and local-environment metadata. Sanitized excerpts can be provided privately.

algiver · 13 days ago

I am having this same or a very similar issue.

it-yusha · 13 days ago

Possibly related additional observation from a newer build: this may involve the same history-hydration subsystem, although the visible symptom here was a blank task pane rather than the entire window remaining on the logo screen.

Environment:

  • ChatGPT/Codex Desktop 26.810.50856 (build 6644)
  • App server 0.148.0-alpha.9
  • macOS arm64

On August 15, 2026, I reproduced a long blank task pane when opening a task with little or no visible chat history. This indicates that the selected task's own transcript size is not sufficient to explain the delay.

Sanitized desktop logs showed congestion in the app-wide App Server request queue across multiple conversations:

  • thread/resume took up to 103,918 ms
  • thread/turns/list took up to 94,513 ms
  • 77 thread/turns/list requests exceeded 10 seconds
  • queueWaitMs reached 60,006 ms
  • Two requests expired while queued
  • Slow requests were associated with tail_history and thread_hydration
  • Related errors included App server request expired while queued, Failed to load older thread turns, and Failed to load remaining thread turns after resume

Multiple tasks were being resumed or hydrated in the background through the same queue. A small task could therefore remain blank while waiting behind history requests for other tasks.

The total local history corpus may still increase the background workload, so this complements the oversized-history observation above rather than ruling it out. The immediate bottleneck in this reproduction appears to be shared request-queue congestion and cross-task hydration, rather than only the size of the task currently being opened.

Raw logs are not attached publicly because they contain conversation and local-environment metadata.

it-yusha · 4 days ago

Follow-up to my earlier observation:

Since around August 20, the original logo/loading-screen hang reported in this issue has not recurred at all in my environment. I no longer need to open a New Window or restart the app to recover the primary window. Because the hang itself has stopped occurring, I have also not experienced the associated loss of in-app browser state.

Around the same time, I made the following changes:

  • Moved ongoing work from an old local thread whose history had grown to approximately 14.6 GB into a completely new local successor thread in the same project, rather than branching the old thread
  • Transferred only the current state, confirmed decisions, source-of-truth locations, and remaining work
  • Reassigned the related recurring task to the successor thread
  • Verified normal production work in the successor thread
  • Archived the old thread without deleting its history or backups

Before archiving the old thread, after restarting the desktop app, another central thread took approximately 55 seconds to display its conversation history. After archiving, the same measurement took 27 seconds and 31 seconds across two restarts, for an average of 29 seconds—about 47% faster. The composer was usable immediately in both cases; send latency was not measured.

The successor production thread has remained stable and responsive since the migration.

The ChatGPT desktop app was also updated during this period, so I cannot determine whether the original renderer freeze was resolved by the app update, the reduced history-hydration workload, or a combination of both. The immediate before-and-after measurements suggest that archiving the very large inactive thread materially reduced the shared loading workload, consistent with the queue-congestion diagnostics in my previous comment.

For now, this issue is resolved in my environment. I will leave the issue open and report again if the original primary-window hang recurs.