[Windows][26.924.1866.0] Desktop stuck on gray loading screen while backend and Pet remain active

What version of the Codex App are you using?

Windows Store/MSIX package:

OpenAI.Codex 26.924.1866.0

Package full name:

OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0

What platform is your computer?

Windows x64.

What issue are you seeing?

Immediately after updating Codex Desktop to 26.924.1866.0, the main window opens as a gray screen with an infinite loading spinner and never becomes usable.

The interesting part is that the Codex backend is clearly still alive:

tasks started remotely through SSH / phone continue to run;
the Codex Pet/avatar overlay in the same Windows app still shows live progress from those tasks;
thread/list and thread/read requests return successfully with errorCode=null;
the main renderer then repeatedly logs Conversation state not found;
incoming remote-task events are initially logged as Received turn/started for unknown conversation, after which Desktop emits Rebinding placeholder latest turn to incoming event and continues receiving reasoning progress;
this happens for both the primary renderer and the avatarOverlay renderer.

So the app-server/backend path appears responsive, while the Desktop conversation-state / hydration layer does not recover and the primary UI remains stuck on the loader.

The problem started immediately after the update. I have not reset or deleted ~/.codex because the backend sessions are still working correctly.

Relevant sanitized log excerpts

Desktop logs are under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\...

Representative startup/session sequence:

info  [AppServerConnection] response_routed ... method=thread/read ... errorCode=null
error [electron-message-handler] Conversation state not found conversationId=<redacted> rendererWindowAppearance=primary

info  [AppServerConnection] response_routed ... method=thread/list ... errorCode=null

The same pattern repeats across multiple existing conversations:

info  [AppServerConnection] response_routed ... method=thread/read ... errorCode=null
error [electron-message-handler] Conversation state not found ... rendererWindowAppearance=primary

When a task is started remotely over SSH:

error [electron-message-handler] Received turn/started for unknown conversation ... rendererWindowAppearance=avatarOverlay
error [electron-message-handler] Received turn/started for unknown conversation ... rendererWindowAppearance=primary

info  [AppServerConnection] response_routed ... method=thread/read ... errorCode=null

error [electron-message-handler] Conversation state not found ... rendererWindowAppearance=avatarOverlay
error [electron-message-handler] Conversation state not found ... rendererWindowAppearance=primary

A few seconds later the event stream partially recovers:

warning [electron-message-handler] Rebinding placeholder latest turn to incoming event ... rendererWindowAppearance=avatarOverlay
warning [electron-message-handler] Rebinding placeholder latest turn to incoming event ... rendererWindowAppearance=primary

info [electron-message-handler] Reasoning summary item completed ... rendererWindowAppearance=primary
info [electron-message-handler] Reasoning summary item completed ... rendererWindowAppearance=avatarOverlay

This matches the visible behavior: the Pet continues to show task progress while the main window remains stuck on the gray loading screen.

No recent Crashpad reports were present in the checked MSIX Crashpad reports directory.

Steps to reproduce

Have Codex Desktop working normally on Windows.
Update to 26.924.1866.0.
Launch Codex Desktop.
Observe the gray window with an infinite loading spinner.
Start or continue a Codex task from another client/remote SSH session.
Observe that the Windows Pet/avatar overlay still shows live task progress while the primary Desktop UI never finishes loading.
Check Desktop logs: successful thread/read / thread/list responses are followed by repeated Conversation state not found and unknown conversation renderer errors.

Expected behavior

The Desktop renderer should hydrate/register conversation state after successful thread/list / thread/read responses and finish loading the main UI.

A remote task event should not remain unknown to the primary renderer after the backend has successfully returned the thread state.

Additional information

This looks like a Desktop renderer/conversation-state regression rather than a broken Codex backend:

remote tasks continue executing;
the Pet overlay continues receiving progress;
app-server responses are successful;
the primary UI alone remains stuck.

Potentially related issues with similar log fingerprints include #32737, #47054, #47985, and the recent startup/loading regression #48148, but this report is specifically for Windows Desktop 26.924.1866.0 and reproduces immediately after updating to that build.

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

[Linux Desktop][Regression] Codex UI hangs after update; thread_hydration times out while app-server remains responsive #48208
[Linux] Cannot open any previous chats after update, stuck on Loading #48171

Powered by Codex Action

I can reproduce this on the same Windows Store/MSIX build, OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0, on 2026-09-26 (UTC+8).

The desktop window stays dark with a centered loading spinner indefinitely. The web content exposes app://-/index.html, but the normal sidebar and composer never appear.
Windows Event Viewer recorded Application Hang (Event ID 1002) at 08:57:38 and WER MoAppHang (Event ID 1001) at 08:57:41. ChatGPT.exe file version: 154.0.8037.57.
Rebooting Windows, closing and reopening the app window, and Ctrl+R did not resolve it.
Background Codex tasks remain responsive from the remote client while the desktop UI is unusable.
I have not reset the app or cleared local Codex data, to preserve existing sessions.

This appears to match the UI loading failure reported here. Please advise if there is a safe workaround or additional diagnostic information that would help.

I’m seeing the same issue on Windows with version 26.924.1866.0.

Environment

Windows 11
Package: OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0
ChatGPT web works normally
Codex CLI works normally and can authenticate / call models
Desktop app launches, but stays permanently on the gray/white loading screen with the spinner

What I already tried

Reset the Windows app
Uninstall + reinstall from Microsoft Store
Repaired / verified WebView2 Runtime
Fully restarted Windows
Killed all ChatGPT processes
Tested Windows system proxy
Tested Clash Verge TUN mode
Added AppContainer / loopback exemption for ChatGPT
Renamed .codex/config.toml so the app generated a fresh config
Tested with a newly generated local config
Verified that the backend / Codex CLI itself is still functional

None of these fixed the desktop UI.

I also noticed that the installed package is healthy enough to launch multiple ChatGPT.exe processes and WebView2 processes, but the main UI never finishes loading.

Trying to launch the packaged ChatGPT.exe directly also results in:

ChatGPT failed to start.
The process has no package identity.

This looks very similar to a regression specifically affecting the Windows desktop app in 26.924.1866.0, rather than a general connectivity or account issue.

For now I’ve stopped further local troubleshooting because the web app and Codex CLI both work normally.

Happy to provide additional logs or diagnostics if needed.

Update: the CDP reload workaround recovered the desktop UI on this Windows MSIX build (26.924.1866.0). The user has now visually confirmed that the normal UI and composer are visible.

Successful sequence in this run:

Fully close the ChatGPT desktop processes.
Launch the Store app through IApplicationActivationManager.ActivateApplication using AUMID OpenAI.Codex_2p2nqsd0c76g0!App, with --remote-debugging-address=127.0.0.1 --remote-debugging-port=<local port> so package identity is retained. Direct executable launch did not expose the debugging target in this run; AppX activation did.
Wait for the initial startup to reach the stuck state and for the app://-/index.html debugging target to be available.
Send CDP Page.reload with { "ignoreCache": true } to that target.

Timing observation: a reload sent immediately when the debugging target first appeared did not recover the UI. Later inspection still showed 56 DOM elements, no body text and no visible editable controls. A second reload after startup had settled restored the UI within about 10 seconds: 2,075 DOM elements and one visible editable control. A subsequent check showed 3,187 DOM elements and the composer remained available.

The listening socket was verified as 127.0.0.1 only. No app reset, reinstall, or deletion of local Codex data was used.

This is a temporary workaround, not a confirmed permanent fix. A normal restart has not been retested because the user needs the recovered app for work. The debugging listener remains active until this diagnostic app instance exits.

Confirming the same regression on Windows with Microsoft Store package OpenAI.Codex 26.924.1866.0 (x64).

Behavior

The app usually launches to the gray/infinite loading spinner and never becomes usable.
Web and mobile ChatGPT remain fully functional.
Importantly, the desktop app occasionally does get through startup. When that happens, new chats, existing/long conversations, and Codex all work normally.
After closing the desktop app and launching it again, it typically returns to the infinite loading spinner. This makes the issue look specifically tied to the startup/session-hydration path rather than general account/network/backend availability.

Diagnostics

Windows Event Viewer records an application hang for ChatGPT.exe with:
- HangType: Top level window is idle
Package status:
- Name: OpenAI.Codex
- Version: 26.924.1866.0
- SignatureKind: Store
- Status: Ok
Desktop logs show:
- app-server transport starts successfully;
- Codex CLI initializes successfully;
- the main window reaches window ready-to-show;
- React root render is requested;
- authentication/account checks succeed.
This is consistent with the backend/runtime starting while the primary desktop UI fails to finish startup reliably.

Troubleshooting already tried without a stable fix

Repair
Reset
Full uninstall/reinstall from Microsoft Store
Reboot
End all ChatGPT/Codex/OpenAI processes
Re-register the AppX package
Clear residual Codex/OpenAI local data and runtime caches, then reinstall cleanly
Different network / VPN off
Firewall checks
Package integrity/status check

A clean reinstall can still produce the same behavior. The fact that the app sometimes starts successfully and then works normally until the next close/relaunch may be useful for narrowing down the regression.

I can provide sanitized desktop logs and Event Viewer details if needed.

Additional reproduction and startup timing evidence for this issue on Windows 25H2 build 26200.9457 x64, with OpenAI.Codex 26.924.1866.0 (Owl runtime 26.924.20706; app log build 11431).

The desktop opens a dark window with a permanent centered spinner on every tested launch. Ctrl+N and Ctrl+, do not reveal a usable interface. A connected phone can still send messages and execute tasks on the same PC.

Verified recovery attempts

Multiple desktop restarts: no recovery.
Windows Settings Repair completed successfully at 2026-09-26 06:33:33 UTC. AppXDeploymentServer event 666 records result 0x0. The spinner persisted.
Temporary HTTP, JavaScript and graphics caches in the active desktop profile were moved to a backup; the app was relaunched. The recovery transcript confirms completion at approximately 06:40:05 UTC. The spinner persisted.
The production Windows update feed returned the already-installed version 26.924.1866.0 when checked.

Earlier Repair attempts failed with 0x80073D02. A separate CodexSandboxService.OpenAI.Codex service was running from the package directory. Repair subsequently succeeded after shutdown work, but that did not fix startup.

Sanitized post-cache-refresh startup evidence

2026-09-26T06:40:18.704Z [AppServerConnection]
initialize_handshake_result durationMs=518 outcome=success transportKind=stdio

2026-09-26T06:40:23.865Z [chatgpt-account-lookup]
authenticatedAccountPresent=true authMethod=chatgpt result=succeeded

2026-09-26T06:42:23.209Z client.performance.span
buildNumber=11431 clientPlatform=win32 hostType=electron initialSurface=home
name=app_start outcome=failure reason=timeout durationMs=125860.8
marksMs={"renderer_entry_evaluated":4515.3,"host_services_ready":4945.8,"host_startup_ready":5436,"renderer_ready":5465.4,"settings_ready":5930.6}
rendererWindowAppearance=primary rendererWindowVisible=true

An earlier launch failed after 122469.5 ms with the same initialSurface=home and the same initialization milestones reached.

Renderer breadcrumbs also contain:

Matched leaf route at location "/" does not have an element or Component.
Conversation state not found conversationId=[OMITTED]

Their causal role is unconfirmed; the conversation-state errors occur during phone-originated activity.

No Windows Reset, uninstall, fresh-profile test, authentication reset, or modification of .codex chats/configuration/databases was performed. The existing profile and sign-in are being preserved. The clean-profile and child-app-server-only restart workarounds have not been tested on this machine.

Please investigate the remaining startup dependency after settings/account initialization. A workaround that preserves the existing sign-in and local data would be especially useful.

Same issue on Windows x64 with Codex Desktop 26.924.1866.0.

The app-server handshake succeeds, and renderer, host, and settings_ready initialization all complete. However, the main UI never reaches shell/sidebar/home visibility, and app_start times out after approximately 121 seconds.

Additional isolation results:

A completely clean Chromium user-data-dir still reproduces the failure.
Launching with --disable-gpu also reproduces it, with software/WARP rendering confirmed.
An in-place downgrade to 26.917.9434.0 immediately restores normal startup using the same existing user data and configuration.

Taken together, these results strongly point to a regression in 26.924.1866.0 rather than a corrupted local Chromium profile or a GPU rendering issue. The specific internal cause remains unconfirmed.

Adding a failed-versus-successful startup comparison from another affected Windows machine. The previous version worked normally; after updating, the primary window stayed on a dark loading screen with no sidebar or composer, while the pet overlay and backend remained responsive. A later launch recovered on the same new build, without a completed downgrade.

Environment:

Windows 11 x64; logged OS version 10.0.26200.
Microsoft Store/MSIX: 26.917.9434.0 -> 26.924.1866.0.
Desktop bundle: 26.924.20706; frontend build: 11431.
Frontend commit: 97cf4a3c7cee97ad6cbb13cb9ab228321db3a385.
Bundled CLI: 0.158.0-alpha.2.

The logs contain six failed primary-window app_start spans on build 11431, timing out after approximately 121-138 seconds. Each reached renderer, host, and settings readiness, but none recorded shell_visible, home_visible, or sidebar_ready. The loading screen persisted beyond the telemetry timeout.

Here is one failure compared with the later successful launch. All timestamps are UTC on 2026-09-26; milestone values are milliseconds from startup.

Logged milestone	Failed launch	Successful launch
Frontend build	11431	11431
`renderer_ready`	1124.4	1110.5
`host_startup_ready`	1128.4	1114.1
`settings_ready`	1479.4	1466.7
Primary app routes mounted	Not recorded	10438
`shell_visible`	Not recorded	12584.1
`home_visible`	Not recorded	12586.2
`sidebar_ready`	Not recorded	13131.4
`app_start` result	failure / timeout	success
`app_start` duration	120995.6	13131.5

Selected sanitized log fields:

2026-09-26T07:12:59.507Z [chatgpt-account-lookup]
authenticatedAccountPresent=true authMethod=chatgpt result=succeeded

2026-09-26T07:14:57.399Z client.performance.span
buildNumber=11431 rendererWindowAppearance=primary
name=app_start outcome=failure reason=timeout durationMs=120995.6

2026-09-26T07:49:04.790Z [startup][renderer]
app routes mounted after 10438ms rendererWindowAppearance=primary

2026-09-26T07:49:07.570Z client.performance.span
buildNumber=11431 rendererWindowAppearance=primary
name=app_start outcome=success reason=null durationMs=13131.5

During the failed launch, the logs also recorded a requested React root render and mounted avatar-overlay routes. This is evidence against interpreting an empty debugging-target list from an earlier diagnostic launch as proof that the renderer never started. Before the update, build 10954 recorded a successful startup in 6127.6 ms.

Some boundaries that may help avoid misleading conclusions:

Authentication/account lookup succeeded during the failure. Backend requests continued working.
Restoring an unavailable optional local MCP service did not resolve the UI stall; subsequent launches still failed.
Cache/profile backup-and-reset attempts were followed by further failures. Because packaged Windows AppData redirection complicates identifying the active profile, this was not a verified clean-profile test.
Direct executable launches introduced a separate package-identity/updater error. Correct packaged activation also reproduced the UI stall, so that direct-launch error does not explain the original problem.
An attempted downgrade staged the old MSIX before the successful relaunch. However, the running executable, registered version, frontend build, and commit still identified the new version. This was not a successful rollback, and the intervening troubleshooting changes prevent attributing recovery to a single action.

During the successful launch, logs recorded Authenticated workspace changed request cancellations, a successful account lookup, and runtime configuration refreshes before the primary routes mounted. The runtime configuration's latest value changed from 26.923.10815 to 26.905.11957; routes mounted about 51 ms after the latter log. This is only a timing correlation, not a confirmed cause or workaround. No completed runtime upgrade was verified.

The recovered UI was visually confirmed, but repeatable recovery and the exact blocked dependency remain unconfirmed. Could the team investigate the startup dependency between settings/account readiness and primary route mounting, and expose its waiting state or a recoverable timeout instead of leaving the user on an indefinite spinner?

I’m seeing the same startup failure on Windows with the Store package OpenAI.Codex 26.924.1866.0 and a ChatGPT Pro subscription. Since the update, the desktop window remains on the central loading animation indefinitely.

My startup log shows that the main frame loads, the app-server responds, and ChatGPT account lookup succeeds (authenticatedAccountPresent=true, result=succeeded). The UI still never becomes usable. Restarting the app and renaming the ShaderCache did not help. I have preserved my .codex directory and session data.

Please provide a fix or a supported rollback path for this build.

Update to my earlier report: the infinite loading screen recurred on Windows Store/MSIX 26.924.2738.0. On 2026-09-26, the CDP reload workaround described above recovered the main UI, and I visually confirmed that it was usable.

The successful sequence on this machine was:

Fully close the desktop processes belonging to the registered Codex package.
Use IApplicationActivationManager.ActivateApplication with AUMID OpenAI.Codex_2p2nqsd0c76g0!App and arguments --remote-debugging-address=127.0.0.1 --remote-debugging-port=<unused local port>. Preserve package identity rather than launching the packaged executable directly.
Verify that the debugging listener belongs to the desktop process and listens only on 127.0.0.1.
Locate the app://-/index.html page through /json/list, connect to its CDP WebSocket, and let startup settle. In this run, I waited 60 seconds; the main page still had only 56 DOM elements, zero body text, and no visible editable controls.
Send Page.reload with {"ignoreCache":true} to that main-page target.

Observed results:

Check	DOM elements	Visible editable controls
Immediately before reload, after the 60-second wait	56	0
Approximately 5 seconds after reload	1,848	1
Approximately 15 seconds after reload	2,030	1

One reload was sufficient in this run. The interface remained available at the follow-up check, and I confirmed recovery visually.

A practical detail for anyone running this repair from inside Codex: an initial helper launched with Start-Process was terminated when the desktop process exited, so that attempt never reached activation or CDP reload. The successful helper was launched independently through Windows WMI process creation, in the interactive user's session, with IsProcessInJob returning false. That allowed it to survive closing Codex and finish the recovery sequence.

I have made a local launcher around this sequence. This is still a temporary workaround, not a confirmed root-cause fix or evidence that ordinary restarts are now reliable. This recovery attempt did not reset or reinstall the app, remove authentication data, or delete chats/configuration. The loopback debugging listener remains active until this diagnostic desktop instance exits. No raw logs, screenshots, account identifiers, or private paths are attached.

Confirming the same persistent Windows desktop loading screen on OpenAI.Codex 26.924.2738.0 (x64), after upgrading from 26.924.1866.0. It reproduces on two separate PCs (home and office) with the same account, while Codex web works normally.

On the affected PC, Windows 11 build 26200, the desktop startup log shows:

initialize_handshake_result ... outcome=success and app-server state connected
main frame loaded and ready-to-show
React root render requested; ChatGPT account lookup authenticatedAccountPresent=true ... result=succeeded
[electron-fetch-handler] codex-home request hostId=undefined
subsequent config/read, windowsSandbox/readiness, app/installed, and plugin/installed responses route successfully, yet the primary window stays on the loading screen.

An earlier run on 26.924.1866.0 recorded app_start outcome=failure reason=timeout after approximately 166 seconds. The captured 26.924.2738.0 run was stopped after about a minute, so I cannot claim a new-build timeout from that log. The recurring fs/readFile OS error 3 lacks a path in the available log and is not established as the blocker. The later EPIPE occurred during shutdown.

Troubleshooting already tried without improvement: update to 26.924.2738.0, Windows app Repair, elevated sandbox provisioning (reported complete), and reversible backup/rename of the package's LocalCache\Local\Codex and LocalCache\Roaming\Codex\web folders. I have kept ~/.codex and the backups intact. No raw logs or account identifiers are posted here.

This adds a cross-machine reproduction and confirms the current Store build is affected.

Update from the original reporter (2026-09-26):

I installed the newer Windows desktop update offered today, but the startup behavior did not improve: the main window still gets stuck on the gray loading screen/spinner.
Interestingly, yesterday the app did successfully get through startup once on the affected 26.924 line. The UI was somewhat sluggish, but the new/changed left sidebar was visible and the app was otherwise usable.
At that time, the separate widespread 401 / sk-svcac... backend outage prevented meaningful Codex work.
After restarting the desktop app as a test, it returned to the infinite loading spinner.
Today, after approximately 7 launch attempts, the app finally completed startup again and is currently usable. I did not change configuration, reset local data, reinstall, remove auth.json, or apply any workaround between the failed and successful attempts.

This makes the failure clearly intermittent rather than permanent. Multiple consecutive launches can remain stuck indefinitely, followed by a normal startup on the same installation and local state. That seems consistent with a startup race / route-mounting / hydration dependency rather than permanently corrupted local data.

I have not reset or deleted ~/.codex or local session history.

Additional reproduction of the Windows startup hang, with a directly observed pending startup gate and repeated recovery after a renderer-only reload.

Environment

Windows 11 Pro 25H2, build 26200.9550, x64.
Current Microsoft Store/MSIX package: OpenAI.Codex 26.924.2738.0.
Desktop log release: 26.924.22138, build 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1.
The symptom also occurred before the update on package 26.924.1866.0 / desktop release 26.924.20706.

Reproduction and expected behavior

Fully exit the desktop app.
Launch normally with the existing signed-in profile and local history.
The primary window stays gray with the loading indicator. Reopening normally can reproduce the failure.

Expected: startup completes and the existing projects and conversations become available. This reproduction is from one affected installation; a clean-machine reproduction has not been established here.

Observed startup gate

A bounded, read-only inspection of the primary renderer found its gateway OAuth readiness state still loading. The installed route-selection code returns the loading UI while this condition remains pending.

In the failing cold-start log, the local app-server handshake and account/read succeed, but no account/gatewayOAuth/read response for the primary renderer appears before the startup timeout. Other windows can initialize independently, so their successful startup events must not be mistaken for primary-window recovery.

Selected log fields, all timestamps UTC on 2026-09-26; unrelated fields and identifiers omitted:

19:04:21.061 initialize_handshake_result durationMs=224 outcome=success
19:04:23.440 response_routed method=account/read durationMs=10 errorCode=null originWebcontentsId=1
19:06:22.718 app_start durationMs=122149.2 outcome=failure reason=timeout rendererWindowAppearance=primary

Temporary recovery, not a fix

Starting with the existing profile, waiting about 25 seconds, then issuing exactly one CDP Page.reload to the stalled primary page recovered the interface while leaving the app-server running. The debugging listener was restricted to localhost. The reload did not alter authentication flags, patch installed app code, or reset chat databases.

On the latest diagnostic launch, the primary gate was captured as loading before reload. After reload:

19:38:33.911 response_routed method=account/gatewayOAuth/read durationMs=10 errorCode=null originWebcontentsId=1
19:38:36.937 app_start durationMs=5990.1 outcome=success rendererWindowAppearance=primary
19:38:37.200 app routes mounted after 6624ms rendererWindowAppearance=primary

The recovered project/chat interface was visually checked. Two earlier launches with the same renderer-reload workaround also recorded successful primary startup spans of 18129.7 ms and 9756.8 ms. These are the app's post-reload startup metrics, not total time from launching the process. Ordinary cold startup remains unreliable.

This is consistent with an initialization/state-propagation problem around gateway readiness, but the exact cause is not established. A missing logged response alone does not prove whether the request was never issued or its result was not consumed. Related gateway-read observations also appear in #48377.

Could the team investigate this pending primary-renderer startup gate and provide a supported fix or recovery path that preserves local history? A recoverable timeout or retry with a useful error would also help avoid an indefinite gray window.

No raw logs, screenshots, chat content, account identifiers, credentials, or personal filesystem paths are attached.

@ezoterik

@ezoterik @knoeferl @jumptosky — follow-up to the gateway-readiness observation, with a causal test from another Windows Stable installation (MSIX 26.924.2738.0; app-server 0.158.0-alpha.2.1).

On the failing cold launch, the app-server was connected but the primary renderer's appServerVersion$ state was unset. Gateway OAuth readiness stayed loading, and the internal gateway-oauth/read query (which issues the app-server account/gatewayOAuth/read request) was never created. Replaying the application's own ready initialization message caused the full UI to mount in under one second. Setting appServerVersion$ to the exact version already reported by the app-server also created and completed the gateway query; changing connection state alone did not help. A later cold launch reproduced the spinner.

The packaged flow is consistent with the initialization snapshot being sent before the renderer's general message handler subscribes, with that event not buffered. This strongly identifies the immediate blocker on this installation, while the precise upstream source-level cause still needs maintainer confirmation.

This supports a related startup-gate failure path, but it does not explain the original Conversation state not found errors after successful thread/list / thread/read calls. Full evidence and test details are in my related reproduction on #43960.

Confirmed: the CDP reload workaround also recovered the UI on my Windows machine with OpenAI.Codex 26.924.1866.0.

My previous state:

Stable desktop app stuck indefinitely on the gray loading spinner
ChatGPT Web worked
Codex CLI worked
ChatGPT Beta worked

What worked:

Fully closed all ChatGPT.exe processes.
Launched the Store/MSIX app through IApplicationActivationManager.ActivateApplication using:
OpenAI.Codex_2p2nqsd0c76g0!App
Started it with a localhost-only CDP port:
--remote-debugging-address=127.0.0.1 --remote-debugging-port=<port>
Waited until app://-/index.html became available.
Let startup settle for ~30 seconds.
Sent:
Page.reload { "ignoreCache": true }

After the reload, the full ChatGPT UI appeared successfully, including the sidebar, conversation history, and composer.

No reset, reinstall, cache deletion, auth reset, or .codex data deletion was required.

So on my installation, this strongly confirms that the backend/app-server was healthy and the failure was in the primary renderer startup/init path.

This is still only a temporary workaround; I have not yet confirmed whether a normal cold restart remains reliable.

Title:
[Windows][26.924.1866.0] ChatGPT/Codex Desktop stuck indefinitely on black loading screen after update

What version of the Codex App are you using?

OpenAI.Codex 26.924.1866.0 x64

Bundled Codex CLI:
codex-cli 0.158.0-alpha.2

What subscription do you have?

ChatGPT paid subscription

What platform is your computer?

Windows 10 Pro 22H2 x64

OS build:
19045.6466

GPU:
NVIDIA Quadro P620

NVIDIA driver:
31.0.15.5335

What issue are you seeing?

The ChatGPT/Codex Windows desktop app worked normally before the update.

Immediately after updating the desktop application to:

OpenAI.Codex 26.924.1866.0

the application stopped loading correctly.

Every time the app is launched:

The native application window opens successfully.
The window frame and title bar appear normally.
The main client area is completely black.
A small circular loading spinner appears in the center.
The spinner continues indefinitely.
The normal ChatGPT/Codex interface never appears.
No visible error message is shown.
Waiting several minutes does not change the result.
Closing and reopening the application reproduces the same behavior every time.

The web version of ChatGPT works normally on the same computer and account.

The problem started immediately after the desktop application update.

Important observation

The application does not appear to be completely crashed.

During troubleshooting:

ChatGPT/Codex background processes remained running.
Renderer/background components remained present.
Some application background activity continued.
Desktop logs showed AppServer requests being processed without an obvious fatal error.
The main window itself remained permanently stuck on the loading spinner.

This suggests that the backend/app-server can start, while the main desktop renderer / UI bootstrap / conversation hydration path fails to complete.

Steps to reproduce

Use a previously working ChatGPT/Codex Windows desktop installation.
Update the application to OpenAI.Codex 26.924.1866.0.
Launch the application.
The application window opens normally.
The main area becomes black.
A loading spinner appears in the center.
Wait several minutes.
The normal UI never loads.
Close the application.
Launch it again.
The same infinite loading state occurs.

Troubleshooting already performed

The following troubleshooting was completed without resolving the issue:

Windows Settings > Apps > ChatGPT/Codex > Repair
Result: no change.
Windows Settings > Apps > ChatGPT/Codex > Reset
Result: no change.
Verified the installed package:
Name: OpenAI.Codex
Version: 26.924.1866.0
Architecture: x64
Status: Ok
Regenerated the local Codex runtime:
%LOCALAPPDATA%\OpenAI\Codex

The old directory was preserved as a backup and a new runtime directory was generated successfully.
Result: no change.

Regenerated the Chromium/Web profile:
%APPDATA%\Codex\web

The previous directory was preserved as a backup and the app recreated a new profile.
Result: no change.

Checked:
%USERPROFILE%.codex\config.toml

Results:

File exists
No NUL-byte corruption
NUL_BYTE_COUNT = 0
No suspicious context_management.experimental_mode configuration detected

Tested disabling/updating the application updater path.
Result: no change.
Tested multiple Chromium / GPU compatibility launch options, including:

--disable-gpu
--disable-gpu-compositing
--disable-direct-composition
--disable-features=CalculateNativeWinOcclusion
--disable-features=EnableTransparentHwndEnlargement
--force-color-profile=srgb

Result:
The app still remained on the same black loading screen.

Windows Application Event Log did not show a normal application crash corresponding to the failure.
The bundled Codex executable is present and responds normally to:

codex.exe --version

Result:
codex-cli 0.158.0-alpha.2

Expected behavior

The desktop application should complete startup and display the normal ChatGPT/Codex interface.

Actual behavior

The application permanently remains on:

black screen + center loading spinner

and the main desktop interface is unusable.

Regression information

This issue began immediately after updating to:

OpenAI.Codex 26.924.1866.0

The desktop application worked normally before that update.

No relevant Windows, GPU, hardware, or project changes were made at the same time.

Additional note

ChatGPT in the browser continues to work normally on the same account and computer.

The issue therefore appears specific to the Windows desktop application after the 26.924 update.

Please let me know if additional sanitized logs, AppX information, or process diagnostics are required.

Still reproducing on the next Store build: OpenAI.Codex 26.928.1915.0 (Windows 11 25H2, build 26200, x64). #49557 reports the same on 26.928.2636.0.

Observations

4/4 normal cold launches from the Start menu stayed on the loading spinner. In each failing launch the app-server only received the initial thread/list prefetch (plus config/auth/plugin reads); the renderer never issued thread/read, model/list, threadSection/list, mcpServerStatus/list etc. A successful launch issues all of those within ~2 s.
Same renderer signature as above and in Windows desktop startup hangs with missing backend version; initialization handshake replay opens UI #49557: the startup router gate shows the spinner because gatewayOAuthReadiness stays "loading", account/gatewayOAuth/read is never sent, and the early host requests (vscode://codex/codex-home, get-global-state, locale-info, list-automations, inbox-items, experimental-features/list) stay pending/fetching forever. No JS exceptions, no failed network requests.
Not local data: Reset, full uninstall/reinstall, clearing LocalCache and trimming .codex-global-state.json do not help. A standalone codex app-server (same flags as the desktop app, experimentalApi capability) answers thread/list, project/list, account/gatewayOAuth/read and windowsSandbox/readiness in under 200 ms on the same CODEX_HOME, even with a multi-GB sessions/ folder.
Ctrl+R, --disable-renderer-backgrounding, --disable-backgrounding-occluded-windows and --disable-background-timer-throttling do not help.

Possibly relevant (hypothesis, from reading the bundled main-process code)

The main→renderer chunked message sender keeps one queue per webContents and does not send anything else while a chunked transfer is waiting for acknowledgeChunkedMessage (drain() bails out while transfer != null). The renderer only acknowledges a chunk once its message handler processes it. If an early chunked message is delivered before the renderer's receiver is listening, the ack never comes and every later message for that window stays queued. handleLoading() on a renderer reload requeues the stuck transfer, which would explain why a reload after startup has settled reliably recovers the UI, while a reload sent too early does not. I have not confirmed which message gets stuck, so treat this as a pointer rather than a root cause.

Workaround (reliable for me on every launch so far)

A PowerShell launcher that starts the packaged app with a localhost-only DevTools port, lets startup settle, then reloads the main window via CDP until it renders (usually 1–2 reloads). No reset, no data deletion. If the app is already running and healthy, it just brings it to the front.

Caveat: while the app runs, the DevTools port is reachable by any local process on the machine (bound to 127.0.0.1 only). Stop using it once a fixed build ships.

Usage: save as start-chatgpt.ps1, close ChatGPT, then run
powershell -NoProfile -ExecutionPolicy Bypass -File start-chatgpt.ps1
(or put that in a desktop shortcut). Disable the app's own startup entry (Task Manager → Startup apps), otherwise the normal autostart launch will hang.

start-chatgpt.ps1

# Workaround for the ChatGPT/Codex desktop startup hang on Windows (openai/codex#48216, #47795).
# Launches the Store app with a localhost-only DevTools port, waits for startup to settle,
# and reloads the main window until it renders.
$ErrorActionPreference = 'Stop'
try { Start-Transcript -Path "$PSScriptRoot\last-run.log" -Force | Out-Null } catch {}
$Port = 9229
$Pfn = 'OpenAI.Codex_2p2nqsd0c76g0'
$MaxReloads = 6
$Host.UI.RawUI.WindowTitle = 'ChatGPT launcher'

function Show-Error($text) {
    Add-Type -AssemblyName PresentationFramework
    [System.Windows.MessageBox]::Show($text, 'ChatGPT launcher', 'OK', 'Error') | Out-Null
}

trap {
    Write-Host "ERROR: $($_.Exception.Message)"
    Write-Host $_.InvocationInfo.PositionMessage
    try { Stop-Transcript | Out-Null } catch {}
    Show-Error "Could not start ChatGPT:`n$($_.Exception.Message)`n`nLog: $PSScriptRoot\last-run.log"
    exit 2
}

function Invoke-Cdp($wsUrl, $method, $params = @{}) {
    $ws = New-Object System.Net.WebSockets.ClientWebSocket
    $ct = [Threading.CancellationToken]::None
    $ws.ConnectAsync([Uri]$wsUrl, $ct).Wait(5000) | Out-Null
    $msg = @{ id = 1; method = $method; params = $params } | ConvertTo-Json -Compress -Depth 5
    $bytes = [Text.Encoding]::UTF8.GetBytes($msg)
    $ws.SendAsync([ArraySegment[byte]]$bytes, 'Text', $true, $ct).Wait(5000) | Out-Null
    $buf = New-Object byte[] 65536
    $sb = New-Object Text.StringBuilder
    do {
        $task = $ws.ReceiveAsync([ArraySegment[byte]]$buf, $ct)
        if (-not $task.Wait(10000)) { break }
        $sb.Append([Text.Encoding]::UTF8.GetString($buf, 0, $task.Result.Count)) | Out-Null
    } while (-not $task.Result.EndOfMessage)
    try { $ws.CloseAsync('NormalClosure', '', $ct).Wait(2000) | Out-Null } catch {}
    return ($sb.ToString() | ConvertFrom-Json)
}

function Get-MainPage {
    try {
        $list = Invoke-RestMethod "http://127.0.0.1:$Port/json/list" -TimeoutSec 3
        return $list | Where-Object { $_.url -like 'app://-/index.html*' } | Select-Object -First 1
    } catch { return $null }
}

function Test-Rendered($page) {
    if (-not $page) { return $false }
    try {
        $r = Invoke-Cdp $page.webSocketDebuggerUrl 'Runtime.evaluate' @{ expression = 'document.body.innerText.length'; returnByValue = $true }
        return ([int]$r.result.result.value -gt 0)
    } catch { return $false }
}

function Show-ChatGPT {
    $sig = '[DllImport("user32.dll")] public static extern bool SetForegroundWindow(IntPtr h); [DllImport("user32.dll")] public static extern bool ShowWindow(IntPtr h, int c);'
    $u = Add-Type -MemberDefinition $sig -Name W32 -Namespace Launcher -PassThru
    $p = Get-Process ChatGPT -ErrorAction SilentlyContinue | Where-Object { $_.MainWindowHandle -ne 0 } | Select-Object -First 1
    if ($p) { $u::ShowWindow($p.MainWindowHandle, 9) | Out-Null; $u::SetForegroundWindow($p.MainWindowHandle) | Out-Null }
}

# Already running through this launcher and working: just bring it to the front.
if (Test-Rendered (Get-MainPage)) {
    Write-Host 'ChatGPT is already running.'
    Show-ChatGPT
    exit 0
}

Write-Host 'Starting ChatGPT. This can take up to a minute, keep this window open...'
Get-Process ChatGPT -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep -Seconds 3

# Launch inside the package context so the app keeps its package identity.
$exe = (Get-AppxPackage OpenAI.Codex).InstallLocation + '\app\ChatGPT.exe'
Invoke-CommandInDesktopPackage -PackageFamilyName $Pfn -AppId App -Command $exe `
    -Args "--remote-debugging-address=127.0.0.1 --remote-debugging-port=$Port"

$page = $null
for ($i = 0; $i -lt 90 -and -not $page; $i++) { Start-Sleep -Milliseconds 500; $page = Get-MainPage }
if (-not $page) { throw 'The ChatGPT window did not appear within 45 seconds.' }

# Let startup settle first: an early reload does not help.
Start-Sleep -Seconds 12
for ($attempt = 1; $attempt -le $MaxReloads; $attempt++) {
    if (Test-Rendered (Get-MainPage)) {
        Write-Host 'ChatGPT is ready.'
        Show-ChatGPT
        try { Stop-Transcript | Out-Null } catch {}
        exit 0
    }
    Write-Host "Window still stuck, reloading ($attempt of $MaxReloads)..."
    $page = Get-MainPage
    if ($page) { Invoke-Cdp $page.webSocketDebuggerUrl 'Page.reload' @{ ignoreCache = $true } | Out-Null }
    Start-Sleep -Seconds 12
}
if (Test-Rendered (Get-MainPage)) { Write-Host 'ChatGPT is ready.'; Show-ChatGPT; exit 0 }
throw "The window did not load after $MaxReloads reloads. Run the launcher again."

I can confirm that this issue is still reproducible on my Windows PC as of October 1, 2026.

Environment:

Windows 10 Pro 22H2 x64
OS build: 19045.6466
OpenAI.Codex: 26.924.1866.0
Bundled Codex CLI: 0.158.0-alpha.2
GPU: NVIDIA Quadro P620

The app worked normally before the update. Immediately after updating to 26.924.1866.0, every launch gets stuck indefinitely on a black startup screen with the white OpenAI logo / loading indicator, and the normal UI never appears.

I have already tried:

Windows Repair
Windows Reset
Restarting the PC
Regenerating the local Codex runtime
Regenerating the Chromium/web profile
Testing GPU/DirectComposition compatibility flags
Checking config.toml for corruption

None of these resolved the issue.

ChatGPT in the browser continues to work normally on the same PC and account.

This has now persisted for several days, so this is blocking my local Codex development workflow.

Please investigate this Windows startup regression and provide either a fixed build or a supported rollback path.

Update to my earlier reports: Codex now starts normally for me, and I no longer encounter the startup loading-screen issue. This is resolved on my side. Thanks!

Update from the original reporter (2026-10-03):

The startup issue has stopped reproducing on my machine for approximately the last three days.

During that period I have had roughly five consecutive normal launches, including cold starts after shutting Windows down and starting the PC again the next day.

I am no longer using any workaround:

no terminating codex.exe / ChatGPT.exe;
no CDP reload;
no replay of the renderer ready message;
no reset, reinstall, or local-data cleanup.

I just launch the app normally. The startup animation runs briefly and the main UI loads successfully.

There have also been several Microsoft Store package updates during this period. AppX deployment history shows this sequence:

26.928.2636.0
26.928.3736.0
26.928.4866.0
26.930.2377.0
26.930.3748.0
26.930.3930.0

The currently installed package is:

OpenAI.Codex 26.930.3930.0
bundled codex-cli 0.160.0
Package status: Ok

26.930.3930.0 was installed only today, so I cannot attribute the recovery specifically to that build. The reliable-startup period began earlier and has survived multiple package updates.

One additional observation: the microphone/dictation control, which previously was sometimes disabled after startup and could require restarting the app, has also been immediately available on every recent successful launch.

So at this point the issue appears resolved on my installation, but I am deliberately not closing this report yet because several other users reproduced the same startup failure and I cannot confirm that it has been resolved for everyone.

[Windows][26.924.1866.0] Desktop stuck on gray loading screen while backend and Pet remain active #48216

Description

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Relevant sanitized log excerpts

Steps to reproduce

Expected behavior

Additional information

Activity

github-actions commented on Sep 25, 2026

Oliver3026 commented on Sep 26, 2026

zbwm commented on Sep 26, 2026

Environment

What I already tried

Oliver3026 commented on Sep 26, 2026

GYX819 commented on Sep 26, 2026

Behavior

Diagnostics

Troubleshooting already tried without a stable fix

R3ijar commented on Sep 26, 2026

Verified recovery attempts

Sanitized post-cache-refresh startup evidence

qy4747 commented on Sep 26, 2026

TIPSONG commented on Sep 26, 2026

kazdano commented on Sep 26, 2026

TIPSONG commented on Sep 26, 2026

jumptosky commented on Sep 26, 2026

ezoterik commented on Sep 26, 2026

knoeferl commented on Sep 26, 2026

Environment

Reproduction and expected behavior

Observed startup gate

Temporary recovery, not a fix

A10nEsK commented on Sep 27, 2026

zbwm commented on Sep 28, 2026

binhucao-ship-it commented on Sep 30, 2026

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Important observation

Steps to reproduce

Troubleshooting already performed

Expected behavior

Actual behavior

Regression information

Additional note

Quvick commented on Sep 30, 2026

Observations

Possibly relevant (hypothesis, from reading the bundled main-process code)

Workaround (reliable for me on every launch so far)

binhucao-ship-it commented on Oct 1, 2026

TIPSONG commented on Oct 2, 2026

ezoterik commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions