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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   browser

   on Aug 8, 2026
2. github-actions commented on Aug 8, 2026

   

   github-actionsBot

   on Aug 8, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows 11][26.803.5235.0] Renderer OOM auto-reload leaves Codex stuck on loading screen while app-server tasks continue #37541

   Powered by Codex Action
3. juncoflockleader commented on Aug 11, 2026

   

   juncoflockleader

   on Aug 11, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. algiver commented on Aug 15, 2026

   

   algiver

   on Aug 15, 2026

   More actions

   I am having this same or a very similar issue.
5. it-yusha commented on Aug 15, 2026

   

   it-yusha

   on Aug 15, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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.
6. it-yusha commented on Aug 24, 2026

   

   it-yusha

   on Aug 24, 2026

   Author

   More actions

   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.
7. markfxs commented on Sep 14, 2026

   

   markfxs

   on Sep 14, 2026

   More actions

   Additional reproduction on a newer macOS desktop build, with cross-device evidence that the task completed while the primary Mac window remained stale.

   Environment

   • ChatGPT/Codex Desktop: 26.908.40834 (build 8881)
   • macOS 26.6.2 (build 25G83)
   • Apple Silicon (arm64)

   Observed sequence

   1. Start a Codex task remotely from an iPhone.
   2. Return to the Mac and continue the same task in the desktop app.
   3. Send several follow-up prompts from the Mac.
   4. The Mac window remains indefinitely in the Thinking state and displays none of the assistant replies, making the task appear frozen.
   5. Open the same task remotely on the iPhone.
   6. All of the prompts and completed assistant replies are present on the iPhone, including replies that never appeared on the Mac.
   7. The Mac window still remains stale until the UI is recovered separately.

   This indicates that the turn execution and persisted task state completed successfully, while only the Mac renderer or live state subscription failed to catch up.

   Sanitized local evidence

   During the affected period, the Mac desktop log contained 84 occurrences between 2026-09-14T13:07:37Z and 2026-09-14T14:01:12Z of:

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

   At 2026-09-14T14:01:03Z, App Server calls for this active task, including thread/queue/add and thread/queue/list, returned with errorCode=null and targetDestroyed=false for both the primary renderer and another web contents instance. A later chatgpt_pubsub_transport_closed warning was also logged, although it is not clear whether that event was causal.

   No raw logs, prompts, task identifiers, account identifiers, recording names, or local filesystem paths are included here because they may contain private data.

   Expected behavior

   When a turn completes and is persisted, the Mac desktop window should leave the Thinking state and render the completed responses. Switching between iPhone remote access and the Mac desktop app should not leave the primary renderer permanently stale. If the live subscription is lost, the desktop app should reconnect automatically or display an explicit recovery action.

   This looks closely related to the renderer and task-continuation behavior reported here, with an additional cross-device confirmation that the backend task and stored responses remained healthy. It may also be related to #43151.