Windows desktop app stuck on loading screen after update — app_start bootstrap timeout after codex-home request (26.924.2738.0)

Description

After updating the Windows desktop app, the application gets stuck indefinitely on the loading screen.

The browser version of ChatGPT works normally on the same PC.

The issue is reproducible on both my normal home WAN and a mobile hotspot.

Environment

Platform: Windows
Store package: OpenAI.Codex 26.924.2738.0
Build number: 11645
Build commit: 2e782921399a788a842b74ee1944a2e1e6e003a1
App-server version: 0.158.0-alpha.2.1
Windows osRelease from log: 10.0.26200

Reproduction

Launch the Windows desktop app.
The main window appears.
The loading spinner remains indefinitely.
The home UI / composer never becomes available.

Already tried:

Exit and restart
Windows App Repair
Windows App Reset
Uninstall/reinstall from Microsoft Store
DNS cache flush
Different DNS servers
Home WAN and mobile hotspot

The browser version continues to work normally.

Latest reproduction timestamp

2026-09-27 00:15:07 +09:00

Relevant desktop log

The local app-server initializes successfully, authentication succeeds, and ChatGPT pub/sub opens/subscribes. The home/bootstrap request is issued, but startup eventually times out.

ext 2026-09-26T15:15:08.208Z info [AppServerConnection] initialize_handshake_result durationMs=211 initializeRequestId=__codex_initialize__ outcome=success transportKind=stdio 2026-09-26T15:15:08.208Z info [AppServerConnection] Codex CLI initialized 2026-09-26T15:15:09.834Z info [electron-message-handler] [chatgpt-account-lookup] completed accountInfoHttpStatus=undefined accountsHttpStatus=undefined authenticatedAccountPresent=true authMethod=chatgpt failureType=undefined hasEverErrored=false rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true result=succeeded windowType=electron 2026-09-26T15:15:10.321Z info [electron-fetch-handler] codex-home request hostId=undefined 2026-09-26T15:15:12.186Z info [electron-message-handler] chatgpt_pubsub_transport_opened rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true topicCount=1 windowFocused=true 2026-09-26T15:15:12.286Z info [electron-message-handler] chatgpt_pubsub_topic_subscribed catchupCount=0 hadPreviousOffset=false recovered=false rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true topicId=resource-updates 2026-09-26T15:17:08.958Z info [electron-message-handler] client.performance.span backgroundDurationMs=0 buildCommitSha=2e782921399a788a842b74ee1944a2e1e6e003a1 buildNumber=11645 clientPlatform=win32 durationMs=121058.3 hostStartupPhaseDurationsMs={"bootstrap handoff complete":163,"main app.whenReady resolved":0,"registered app protocol":0,"local data migrations completed":0,"registered deep link protocol":0,"startup window revealed":330,"local app-server sqlite initialized":92,"window context initialized":93,"application menu refreshed":5,"bundled plugins reconcile checked":1} hostType=electron initialSurface=home marksMs={"renderer_entry_evaluated":1055.3,"host_services_ready":1073.5,"renderer_ready":1212.6,"host_startup_ready":1217.8,"settings_ready":1563.1} name=app_start outcome=failure processToPreloadDurationMs=3345.137939453125 reason=timeout rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true samplingReason=Bootstrap:Recognized samplingRuleId=1kYHoU5I4stzVcHY9M7LZK:100.00:4 spanId=undefined timingQuality=foreground traceId=undefined wallDurationMs=121057.3

Additional network observations

Unauthenticated curl requests to these endpoints return 403 Forbidden with Cf-Mitigated: challenge:

https://chatgpt.com/
https://auth.openai.com/
https://chatgpt.com/backend-api/me

However, the same curl behavior occurs on both the home WAN and the mobile hotspot, so those curl results do not distinguish the failing and working network cases.

Also:

ws.chatgpt.com:443 is reachable.
A WebSocket upgrade attempt to wss://ws.chatgpt.com/ reaches the server and receives HTTP 404 for / rather than timing out.
The application log shows chatgpt_pubsub_transport_opened and chatgpt_pubsub_topic_subscribed.

Expected behavior

The desktop application should finish bootstrap and display the normal home/composer UI.

Actual behavior

The application remains on the loading spinner and records name=app_start outcome=failure reason=timeout after approximately 120 seconds.

Notes

This began immediately after the desktop app update.

In-app / feedback cannot be submitted because the app never gets far enough to display the composer.

I can provide additional desktop logs or timestamps if needed.

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

[Windows][26.924.1866.0] Codex App stuck on blank screen with infinite spinner at startup #48364
[Windows][26.924.2738.0] Repeated startup/loading hang; Event ID 1002 #48457
Windows desktop app stuck on loading spinner; repeatedly requests macOS-only record-and-replay plugin #48404
[Windows][26.924.20706] Endless startup spinner after update; runtime logs awaiting-framework with undefined bundle version #48377

Powered by Codex Action

Windows Version: 25H2 (OS BUILD 262.00.9550) Same issue here. ChatGPT Windows app OpenAI.Codex 26.924.2738.0, x64, installed from the Microsoft Store. The app opens to a blank window with a loading spinner and never loads. It started with the 26.924 update. I uninstalled and reinstalled; the reinstall first failed with 0x80073CF6, then succeeded after removing the leftover OpenAI packages and installing with winget install 9PLM9XGG6VKS --source msstore. After the clean install, the spinner persists on every launch. chatgpt.com works normally in the browser on the same PC and network.

Additional diagnostic report: reloading the main `index.html` renderer restored the UI

Adding a local reproduction with the same Windows package version 26.924.2738.0, app-server 0.158.0-alpha.2.1, and OS release 10.0.26200 (x64). This adds an observed recovery result, rather than asserting a confirmed common root cause.

Symptom and impact

The ChatGPT Windows desktop app (Chat/Work interface; package OpenAI.Codex, package family OpenAI.Codex_2p2nqsd0c76g0) opened to a dark blank window with a centered, persistent loading spinner. The home screen and existing Local work were inaccessible.

The affected environment already had a signed-in account and Local projects. The startup capture below is from 2026-09-26 16:18:17–16:18:51 UTC. Whether the problem initially began immediately after an update was not established.

Attempts before the successful recovery

PC restart: no improvement reported.
Windows Settings → app Repair: no improvement reported.
Temporarily renaming config.toml and relaunching: no improvement reported.
Running a script to rename selected UI cache directories: no improvement reported. The output confirming which directories existed and were actually renamed was not captured, so this does not rule out all cache/profile issues.
A keyboard reload was suggested, but whether it actually reloaded the main page was not verified.
A first diagnostic Page.reload targeted the first matching page: the main screen remained stuck. Inspection afterward showed that this target was the detached window, not the main window.

An app Reset, full application-data deletion, or reinstall during this troubleshooting sequence was not confirmed. These should not be counted among the verified tests for this reproduction.

Observed recovery — target selection mattered

During local diagnosis, the app was launched with --remote-debugging-port=9222, and its targets were inspected through 127.0.0.1. Two page targets were present:

Main window:     app://-/index.html
Detached window: app://-/detached-window.html?initialRoute=%2Fdetached-window

Both had the title ChatGPT, so selecting a target by title alone or using the first matching page selected the wrong window in the initial attempt.

The successful attempt selected only app://-/index.html, connected to that target's debugger WebSocket, and sent:

{"id":1,"method":"Page.reload","params":{"ignoreCache":true}}

The diagnostic client read the matching response and verified that it did not contain a protocol error. The Chat/Work home screen then appeared, and recovery was confirmed visually and by the affected user. Reloading the detached target and reloading the main target were different tests; the former did not recover the main screen.

This records a single successful recovery, not a permanent fix or a controlled timing experiment. Normal quit/relaunch afterward, recurrence, and reproduction on a fresh profile or another PC have not yet been confirmed. It does not establish that ignoreCache specifically was necessary.

The debugging port was used only for diagnosis. The user was instructed to fully quit the debug-launched app and return to normal launch afterward; completion of that cleanup has not yet been reported. This is not a recommendation to keep remote debugging enabled.

What the existing startup logs do and do not show

The provided capture records successful app-server initialization, an authenticated account lookup, and opening/subscribing to ChatGPT pub/sub. It also records codex-home request, but that line alone does not prove an indefinitely pending request or identify where a response was lost.

Local app-server project migration completed projectCount=3 is a migration-completion report, not an integrity check of every project file or session. No loss of project files or sessions was established.

The Artifact Session host Unix-socket warning and the IPC broadcast-handler warnings are included below for completeness. Their causal relationship to the spinner has not been established. The supplied excerpt spans roughly 34 seconds; it does not itself contain or prove the approximately 120-second startup timeout reported in the original issue.

Redacted startup log excerpts (25 selected original lines; UTC)

Windows account names and UUID identifiers are redacted. This is an excerpt, not the complete log. The large runtime configuration/catalog entry and all chat/project content are omitted. Source line numbers refer to the 92-line capture supplied during diagnosis.

[source line 17] 2026-09-26T16:18:17.793Z warning Failed to start the Artifact Session host errorMessage="Artifact Session host Unix-socket transport is not available on Windows." errorName=Error errorStack="Error: Artifact Session host Unix-socket transport is not available on Windows.\n    at e.start (C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0\\app\\resources\\app.asar\\.vite\\build\\main-DAwJoFgo.js:9:25055)\n    at rlt (C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0\\app\\resources\\app.asar\\.vite\\build\\main-DAwJoFgo.js:1578:74390)\n    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n    at async C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0\\app\\resources\\app.asar\\.vite\\build\\bootstrap-D2PJMYEh.js:144:16204"
[source line 35] 2026-09-26T16:18:17.914Z info [AppServerConnection] Transport start success connectionId=1 hostId=local transport=stdio
[source line 36] 2026-09-26T16:18:18.039Z info [window-manager] window main frame finished load appearance=primary hostId=local startupElapsedMs=223 webContentsId=1 windowId=1
[source line 38] 2026-09-26T16:18:18.066Z info [AppServerConnection] Current reported app-server version: currentVersion=0.158.0-alpha.2.1 hostId=local
[source line 39] 2026-09-26T16:18:18.066Z info [AppServerConnection] initialize_handshake_result durationMs=152 initializeRequestId=__codex_initialize__ outcome=success transportKind=stdio
[source line 40] 2026-09-26T16:18:18.067Z info [AppServerConnection] Codex CLI initialized
[source line 41] 2026-09-26T16:18:18.069Z info [AppServerConnection] app_server_connection.state_changed cause=post_initialize_connection_state connectionError=null currentConnectionId=1 currentState=connecting hasConnection=true hostId=local initialized=true initializeInFlight=false next=connected pendingClientRequests=0 pendingInternalRequests=0 previous=connecting reconnectAttempt=0 reconnectTimerScheduled=false restartInFlight=false targetConnectionId=1 targetReadyState=1 transport=stdio
[source line 42] 2026-09-26T16:18:18.098Z info [host-app-server-projects] Local app-server project migration completed projectCount=3
[source line 43] 2026-09-26T16:18:18.137Z info [startup] [0.361] Host startup critical-path phases completed startupElapsedMs=502 startupPhaseDurationsMs={"bootstrap handoff complete":141,"main app.whenReady resolved":0,"registered app protocol":1,"local data migrations completed":0,"registered deep link protocol":0,"startup window revealed":240,"local app-server sqlite initialized":76,"window context initialized":77,"application menu refreshed":3,"bundled plugins reconcile checked":0}
[source line 49] 2026-09-26T16:18:18.320Z info [window-manager] window ready-to-show appearance=primary hostId=local startupElapsedMs=505 webContentsId=1 windowId=1
[source line 52] 2026-09-26T16:18:19.012Z info [electron-message-handler] [statsig-refresh-diagnostics] React root render requested rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true windowType=electron
[source line 58] 2026-09-26T16:18:19.257Z info [BundledPluginsMarketplace] plugin_marketplace_sync_completed marketplaceName=openai-primary-runtime pluginCount=5 pluginsInstalledAfterWrite=5 pluginsInstalledBeforeWrite=0
[source line 59] 2026-09-26T16:18:19.258Z info [install-primary-runtime] primary_runtime_selection architecture=x64 buildFlavor=prod desiredBundleVersion=undefined frameworkEligible=true frameworkEnabled=false osRelease=10.0.26200 reason=gate-disabled runtimeRoot=C:\Users\[REDACTED_USER]\.cache\codex-runtimes\codex-primary-runtime runtimeSource=archive
[source line 64] 2026-09-26T16:18:19.409Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=4 errorCode=null hadInternalHandler=false hadPending=true method=account/read originWebcontentsId=1 queueWaitMs=0 requestId=[REDACTED_ID] targetDestroyed=false
[source line 65] 2026-09-26T16:18:19.413Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=8 errorCode=null hadInternalHandler=false hadPending=true method=getAuthStatus originWebcontentsId=1 queueWaitMs=0 requestId=[REDACTED_ID] targetDestroyed=false
[source line 67] 2026-09-26T16:18:19.637Z info [electron-message-handler] [chatgpt-account-lookup] completed accountInfoHttpStatus=undefined accountsHttpStatus=undefined authenticatedAccountPresent=true authMethod=chatgpt failureType=undefined hasEverErrored=false rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true result=succeeded windowType=electron
[source line 75] 2026-09-26T16:18:20.424Z info [electron-fetch-handler] codex-home request hostId=undefined
[source line 83] 2026-09-26T16:18:22.206Z info [electron-message-handler] chatgpt_pubsub_transport_opened rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true topicCount=1 windowFocused=true
[source line 84] 2026-09-26T16:18:22.338Z info [electron-message-handler] chatgpt_pubsub_topic_subscribed catchupCount=0 hadPreviousOffset=false recovered=false rendererWebContentsId=1 rendererWindowVisible=true rendererWindowFocused=true rendererWindowId=1 topicId=resource-updates
[source line 86] 2026-09-26T16:18:22.479Z warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed
[source line 88] 2026-09-26T16:18:22.594Z info [window-manager] window ready-to-show appearance=detached hostId=local startupElapsedMs=145 webContentsId=2 windowId=2
[source line 89] 2026-09-26T16:18:22.598Z info [window-manager] window main frame finished load appearance=detached hostId=local startupElapsedMs=149 webContentsId=2 windowId=2
[source line 90] 2026-09-26T16:18:36.604Z info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus
[source line 91] 2026-09-26T16:18:46.864Z info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus
[source line 92] 2026-09-26T16:18:51.883Z info [bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus

Request

Please investigate why the initial home UI remains blocked despite these successful initialization stages, and provide a supported fix or recovery path that preserves Local projects, conversations, and user data. A main-renderer startup/IPC sequencing problem is a hypothesis, not a confirmed root cause in this reproduction. The successful main-page reload should be treated as diagnostic evidence and a temporary recovery, not resolution of the underlying startup bug.

No account email, Windows username, private conversation content, project names, authentication files, or raw session transcripts are included in this report.

Additional reproduction / workaround, based on #48377:

After reading #48377, especially the report that startup may complete if the Codex window is not visible or focused during initialization, I tested the same behavior on my affected system.

I can reproduce a very similar workaround:

Launch the Windows desktop app.
Immediately minimize the app while the loading spinner is visible.
Leave it minimized for about 10 seconds.
Restore the window.
The normal home UI is then loaded and usable.

I tested this specifically because of the observation reported in #48377, and the behavior on my system appears to match it closely.

If I leave the app visible/in the foreground during startup, it can remain stuck on the loading spinner. If I minimize it immediately and wait approximately 10 seconds, startup completes successfully.

This does not prove that #48463 and #48377 have exactly the same root cause, but it adds another independent reproduction consistent with the focus/visibility-related startup behavior described in #48377.

This is only a workaround, not a fix.

Environment:

OpenAI.Codex 26.924.2738.0
buildNumber 11645
Windows osRelease 10.0.26200

Related issue:
#48377

I also ran into this exact same issue on Windows 11 with OpenAI.Codex 26.924.2738.0.

Environment & Observation

OS: Windows 11 (Build 26200)
Version: 26.924.2738.0 (x64) via Microsoft Store
Symptoms: After launching, the app hangs indefinitely on a black window with the loading spinner. The logs confirm name=app_start outcome=failure reason=timeout after ~120 seconds.
Troubleshooting attempted: Clean reinstall, resetting AppData, purging LocalCache and .codex-global-state.json did not resolve it.
Workaround verified: Installing the Microsoft Store "ChatGPT (Beta)" package (OpenAI.CodexBeta_26.727.4816.0) bypasses this issue and loads the UI immediately on the same machine.

I can reproduce the same issue on another Windows 11 25H2 machine, with an important variation: the failure is intermittent rather than 100% deterministic.

Environment:

Windows 11 25H2, OS Build 26200.9550
OpenAI.Codex 26.924.2738.0
app-server 0.158.0-alpha.2.1
MSIX package status: Ok

Observed behavior:

Most launches stop at the white startup window with the center spinner and never reach the home UI.
Fully killing all ChatGPT.exe processes and relaunching may eventually succeed, sometimes only after many attempts.
Ctrl+R and Ctrl+Shift+R do not recover the stuck startup.

Relevant failing-run log sequence (sanitized):

[AppServerConnection] Transport start success
[AppServerConnection] initialize_handshake_result durationMs=230 ... outcome=success
[AppServerConnection] Codex CLI initialized
[AppServerConnection] ... next=connected
[window-manager] window main frame finished load
[window-manager] window ready-to-show
[startup] Host startup critical-path phases completed ... startupElapsedMs=2246
[electron-message-handler] [statsig-refresh-diagnostics] React root render requested
[AppServerConnection] ... method=account/read ... errorCode=null
[AppServerConnection] ... method=getAuthStatus ... errorCode=null
[electron-message-handler] [chatgpt-account-lookup] ... authenticatedAccountPresent=true ... result=succeeded
[electron-fetch-handler] codex-home request hostId=undefined
...
client.performance.span ... name=app_start outcome=failure reason=timeout durationMs=122698.4

Additional checks already performed:

approval_policy = "untrusted" is not present.
WSL is not installed; wsl.exe --status returns immediately rather than hanging.
electron-avatar-overlay-open = false.
The local Codex runtime resolves correctly.
The app-server, renderer window creation, and authentication all succeed before the startup timeout.

This looks very close to the report in this issue: backend/app-server and auth are healthy, codex-home is requested, but the primary UI never completes startup and app_start times out after ~120 s. The intermittent successful launches on the same machine/configuration may be useful for diagnosing a startup race/ordering issue.

Additional reproduction and successful recovery on another Windows 11 system:

Microsoft Store package: OpenAI.Codex 26.924.2738.0 (build 11645), Windows OS release 10.0.26200.
After the update, the app remained on the loading spinner before reaching the usable home/login UI. Browser connectivity and the local app-server were working, so this did not look like a basic network failure.
Restarting the main ChatGPT.exe process did not resolve it. Leaving the app open and terminating only its child codex.exe process running app-server caused the app to spawn a replacement backend; the UI then loaded and became usable.

This confirms the app-server restart as a recovery path on another affected machine, but I have not yet tested whether a later cold start reproduces on this system. No chats, credentials, configuration, or user data were changed.

Hello!
I ran into this problem as well.
The following PowerShell command also helped me: codex logout or Stop-Process -Name codex -Force.

Additional reproduction: renderer initialization replay and renderer reload recover the Windows startup spinner

Adding diagnostic evidence for the same package, build, app-server version and Windows OS release as this issue.

Environment and impact

Windows 11 Pro, OS release 10.0.26200, x64.
Microsoft Store package OpenAI.Codex 26.924.2738.0.
App build 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1.
Bundled app-server 0.158.0-alpha.2.1.
The main desktop window remained on its loading spinner. Remote interaction with the running local service continued to work.

Observed failure

Normal startup opened the primary window and completed authentication, but did not display the home screen or sidebar. The app reached settings_ready and later logged an app_start timeout. The stall also occurred in separate diagnostic instances using isolated app profiles.

Selected fields from one original desktop log event (unrelated fields omitted):

2026-09-27T17:21:46.740Z
name=app_start outcome=failure reason=timeout durationMs=122291.9
marksMs={"renderer_entry_evaluated":2283.7,"host_services_ready":2306.3,"renderer_ready":2474.1,"host_startup_ready":2476.4,"settings_ready":2832.5}

New diagnostic observation

In a separate diagnostic instance, the main app://-/index.html renderer had completed authentication, while its local-host version/capability state remained unavailable and gatewayOAuthReadiness remained loading. The signed-in startup guard continued to render the spinner.

Replaying the renderer's existing initialization message in that diagnostic instance immediately populated the local-host version (0.158.0-alpha.2.1) and displayed the home screen/sidebar:

window.electronBridge.sendMessageFromView({
  type: 'ready',
  initializationOnly: true
});

This is diagnostic evidence consistent with a renderer initialization/state-synchronization problem. It does not establish the exact code defect, timing condition, or a common root cause for all related reports.

Recovery on the original affected app

At approximately 2026-09-27T18:12:38Z, only the stuck primary desktop renderer process was terminated. The app's existing renderer-recovery code reloaded it. The original main app process and the same local app-server process remained running throughout.

The primary window then loaded successfully. The user confirmed that the desktop was working.

Selected fields from the resulting original desktop log event:

2026-09-27T18:12:44.552Z
name=app_start outcome=success reason=null durationMs=4494.2
marksMs={"renderer_entry_evaluated":1239.3,"host_services_ready":1263.4,"renderer_ready":1479.5,"host_startup_ready":1480,"settings_ready":1848.8,"shell_visible":3840.6,"home_visible":3840.7,"sidebar_ready":4494.1}

This recovery did not require resetting the original account, conversation history or configuration. It is an observed workaround, not a permanent fix. A subsequent full quit and cold launch of the original app has not been verified after this recovery. Temporary diagnostic instances and debugging connections were closed afterward.

Doctor results after recovery

codex doctor --json using bundled version 0.158.0-alpha.2.1 reported successful desktop app-server initialization, configured authentication, readable configuration, a consistent installation, HTTP endpoint reachability and a successful Responses WebSocket handshake.

Its overall status was warning, with warnings for optional MCP configuration issues, unverified endpoint-protection exclusions, differing rollout-file/state-database inventories, and TERM=dumb in the noninteractive diagnostic run. Their relationship to the startup stall has not been established; these results were collected after recovery.

Please investigate initial renderer readiness/state delivery and provide a supported fix or recovery path that preserves local conversations and configuration. The report includes selected diagnostics only; account identifiers, authentication files, private conversations and raw network traces are omitted.

I can reproduce this on Windows 11 (OS release 10.0.26200, x64) with Microsoft Store package OpenAI.Codex 26.924.2738.0 (build 11645) and app-server 0.158.0-alpha.2.1.

After the update, six launches stayed on the loading spinner. In each failed launch, the local app-server connected, authentication succeeded, and the desktop log recorded codex-home request hostId=undefined. It never recorded codex-home request hostId=local or [startup][renderer] app routes mounted. The last failed launch began at 2026-09-27 19:36:52 UTC. Its app-server was connected by 19:36:53; the home request appeared at 19:36:56; it still had not mounted the routes when I closed it at 19:37:17. No explicit startup exception was logged.

A subsequent launch of the same build, beginning at 19:38:42 UTC, succeeded: codex-home request hostId=local appeared at 19:38:54 and app routes mounted at 19:38:57. This shows the failure is intermittent on this machine. The previous desktop build had loaded successfully earlier that day.

I also tried a fresh window-state file and a minimal config.toml during the failed launches; neither got the UI past Loading. I restored my settings and state afterward. Later file changes occurred after the successful launch and cannot explain that recovery. I cannot identify the exact code-level trigger from these logs.

I'm frustrated. I spent about 30 minutes just getting the app usable again after this update. Please investigate the transition from the first codex-home request to local home/renderer readiness and provide a reliable fix that preserves existing conversations, projects, and settings. I can provide redacted log excerpts if useful.

@xavierbarata

Can confirm that the workaround mentioned by @xavierbarata and @derectim worked for me as well on Windows 11 (OS Build 26200, package OpenAI.Codex 26.924.2738.0).

Leaving the app open on the loading spinner and running:
powershell Stop-Process -Name codex -Force
caused the parent ChatGPT.exe process to immediately respawn the backend app-server (codex.exe). The desktop log transitioned from codex-home request hostId=undefined to codex-home request hostId=local, and the full UI (home, sidebar, chat routes) loaded and became usable right away.

Update (edited): don't use the Stop-Process -Name codex workaround. It clears the spinner but leaves the renderer half-initialized: several queries (accounts/check, apps/list, rate-limit-status, skills…) stay fetching forever, and sending a message then hangs: thread/start succeeds but turn/start is never sent to the app-server. Kill the renderer processes instead (see the workaround at the bottom). The backend stays up, the reloaded renderer gets the init snapshot, everything resolves, and sending works.

Root cause analysis (26.924.2738.0, Windows 11 26200), verified live via CDP on a stuck window

The spinner comes from the onboarding router gate. Aui() returns null while gatewayOAuthReadiness === "loading". In the stuck renderer that value is "loading"; every other input is resolved (codexFeatureAccess = "allowed", onboarding context and workspace roots = success).
It is "loading" because the local host capabilities atom is still null (the t == null branch in the readiness selector). No ["gateway-oauth", ...] query even exists in the QueryClient cache.
That atom is only filled by the codex-app-server-initialized message. Main broadcasts it once, from completeInitialization(), about 30 ms after the window's main frame loads and about 1 s before the React tree mounts:
```
+0.000s  window main frame finished load
+0.022s  Codex CLI initialized  -> broadcastToWindows(codex-app-server-initialized)
+0.928s  React root render requested
+2.188s  codex-home request hostId=undefined   (never followed by hostId=local)
```
The preload forwards codex_desktop:message-for-view with window.dispatchEvent(new MessageEvent("message")) and no buffering, so that broadcast is dropped. In the stuck state ["vscode","codex-home"] and ["vscode","get-global-state",{"key":"selected-remote-host-id"}] also stay fetching forever.
Replaying electronBridge.sendMessageFromView({type: "ready", initializationOnly: true}) makes main resend the snapshot (codex-app-server-initialized, isSnapshot: true, appServerVersion: 0.158.0-alpha.2.1), and the UI loads immediately. A full renderer reload (CDP Page.reload, or killing the renderer processes so the recovery code reloads them) also recovers cleanly. Killing codex.exe makes main broadcast again, this time to a listening renderer, but the requests that were in flight against the old app-server never settle (see the update above).

Open question: the renderer already sends that same initializationOnly ready on mount (the component is mounted in the stuck tree, above the route that renders the spinner), but in the stuck runs it did not populate the atom. I didn't capture why.

Suggested fixes (any one would do)

Preload: queue message-for-view messages until the app's message listener is attached, then flush.
Renderer: if the local host capabilities stay null while the local connection is connected, re-dispatch ready {initializationOnly: true} with backoff, instead of waiting forever.
Gate: don't block the whole app on gatewayOAuthReadiness === "loading" when gateway OAuth isn't required (the app-server returns required: false instantly for account/gatewayOAuth/read); add a timeout.

User-side workaround (no debug port needed)

If app routes mounted doesn't appear in the newest desktop log within about 12 s, kill only the renderer processes. The app reloads them; codex.exe stays up. Tested on cold start: loads in about 20 s, and sending messages works.

$logs = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs"
$start = Get-Date
Start-Process "shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App"
for ($i = 1; $i -le 3; $i++) {
  $deadline = (Get-Date).AddSeconds(12)
  while ((Get-Date) -lt $deadline) {
    Start-Sleep -Milliseconds 500
    $log = Get-ChildItem $logs -Recurse -Filter '*-t0-*.log' | Where-Object LastWriteTime -gt $start | Sort-Object LastWriteTime | Select-Object -Last 1
    if ($log -and (Select-String -Path $log.FullName -Pattern 'app routes mounted' -Quiet)) { exit 0 }
  }
  Get-CimInstance Win32_Process -Filter "Name='ChatGPT.exe'" |
    Where-Object { $_.CommandLine -match '--type=renderer' } |
    ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }
}

Same issue here.

Package: OpenAI.Codex
Version: 26.924.2738.0
PackageFamilyName: OpenAI.Codex_2p2nqsd0c76g0

Windows desktop app stays indefinitely on the loading spinner.
ChatGPT web works normally.

Already tried Repair, Reset, reinstall, reboot, and checking for Store updates.
No newer update is currently available.

Observed on Sep 28, 2026 (KST).

@kanghyunmin-bot

@kanghyunmin-bot No fixed build yet, but there's a workaround that doesn't touch your data. While the spinner is showing, reload only the UI by killing the renderer processes (the app restarts them on its own):

Get-CimInstance Win32_Process -Filter "Name='ChatGPT.exe'" | Where-Object { $_.CommandLine -match '--type=renderer' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

If a message later stops sending, the same command fixes it without interrupting a running turn. A launcher script that does this automatically is in my comment above: #48463 (comment)

Avoid killing codex.exe instead: it clears the spinner but can leave sending broken. If you've relaunched many times, close the app and kill the leftover processes first (see @AlchTech's comment).

Windows Desktop startup white-screen/spinner recovered immediately after restarting only the ChatGPT renderer processes. The app-server was left running. After the renderer respawned, the UI loaded normally and multi-turn message sending also worked. No cache reset, reinstall, sign-out, .codex modification, or app-server restart was performed.

I can reproduce this issue on Codex Desktop 26.924.2738.0 / build 11645.

The issue is account-dependent on my machine:

Same machine
Same Codex installation
Same network
Same local configuration
Only auth.json/account is changed

Account A starts normally.

Account B works normally in Codex CLI, and Desktop authentication/app-server initialization succeeds, but the Desktop UI gets stuck after settings_ready. shell_visible, home_visible, and sidebar_ready are never reached, and app_start eventually times out after ~121 seconds.

Most importantly, while the affected GUI was stuck, I sent:

Page.reload(ignoreCache=true)

to the main renderer:

app://-/index.html

and the GUI recovered immediately.

Nothing else was changed or restarted before the reload.

This appears consistent with the same renderer/bootstrap startup issue described here rather than a CLI/authentication failure.

I can reproduce this exact issue on the same Windows Codex build.

Environment

Codex Store package: OpenAI.Codex 26.924.2738.0
Bundled app-server: codex-cli 0.158.0-alpha.2.1
Windows x64: 10.0.26200.9457

Symptom progression

Before the startup failure, the desktop app had a persistent composer problem:

Existing conversations allowed text entry, but the Send button remained gray/disabled.
A newly created conversation could initially submit a prompt.
The same existing conversations remained usable through iPhone Remote; the Send button was enabled there and messages could be submitted successfully.
After restarting the desktop app and rebooting Windows several times, the desktop app stopped reaching the home UI entirely.
It now remains indefinitely on the loading spinner, matching this issue.

Fully quitting/reopening the app and rebooting Windows did not resolve it. I have not reset or reinstalled the app because I want to preserve the existing local state and worktrees.

Local-state observations

%USERPROFILE%\.codex is approximately 50 GB, largely because it contains many managed worktrees.
.codex-global-state.json is valid JSON.
Read-only SQLite PRAGMA quick_check checks returned ok for:
- state_5.sqlite
- thread_history_1.sqlite
- logs_2.sqlite
- queue_1.sqlite
- goals_1.sqlite

The fact that the same account and conversations continue to work through iPhone Remote suggests that the conversations and backend account remain available, while the Windows desktop client/bootstrap path is failing.

The earlier disabled-composer behavior also appears related to #46986 and #47489.

I can provide redacted desktop log excerpts and exact reproduction timestamps if maintainers indicate which events are needed. I will not upload raw session transcripts or authentication files because they may contain sensitive information.

@CosmicsString

@CosmicsString You don't need to reset or reinstall. This workaround doesn't touch .codex, worktrees, or any local state. While the spinner is showing, kill only the renderer processes; the app respawns them and the UI loads:

Get-CimInstance Win32_Process -Filter "Name='ChatGPT.exe'" | Where-Object { $_.CommandLine -match '--type=renderer' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

Several people have confirmed it above. The gray/disabled Send button you saw earlier fits the same half-initialized renderer state, so the same command may fix that too without restarting the app.

I’m seeing the same startup hang on Windows 11 with ChatGPT/Codex 26.924.2738.0 (build 11645; Windows 10.0.26200). The desktop window stays on the spinner, while the browser version works. My logs also show app-server initialization and account lookup succeeding, followed by app_start outcome=failure reason=timeout after about 121 seconds. I’ve tried restarting and Windows App Repair/Reset, but the issue persisted.

@Swih

September 29: renderer recovery confirmed; official fix still needed

Following up on my earlier reproduction: on OpenAI.Codex 26.924.2738.0, restarting only the UI renderer restored multi-turn sending for me. My local Fix Codex spinner.cmd shortcut using that method also seems to work. Thank you @Swih and @layibabalola for documenting the recovery and the warning about restarting the app-server.

I have posted the copyable PowerShell recovery steps and renewed escalation on #47316 so users stuck with the disabled Send / one-message-per-chat problem can find them too. Copy unsent drafts before reloading; they may be lost. The recovery targets Codex's renderer and leaves its main process and backend running. Restarting codex.exe instead can leave sending broken later, as reported above.

This confirms a useful session workaround, not a permanent fix or a proven common root cause for every spinner and composer failure.

It is unacceptable that a paid desktop app requires a repair script for basic use. Please provide an official acknowledgement, a permanent fix with a target release or status update, and verification of both startup and repeated follow-up sending. I am also renewing the existing usage-reimbursement request linked in the escalation. Please do not treat users finding a workaround as resolution of the product defect.

Now 26.928.1915.0 is here and shows only endless the app logo. Since days no work possible!

Now 26.928.1915.0 is here and shows only endless the app logo. Since days no work possible!

I can confirm this; I thought they’d fix the issue with the preloader that appears after the logo, but now the logo disappears and the exact same logo pops up again—yet there’s no preloader...

Same issue on Windows 11 — OpenAI.Codex 26.924.2738.0, still present after updating to 26.928.2636.0 (Microsoft Store).

Ruled out (none of these fixed it):

disabling computer-use / unified-computer-use plugins and the node_repl MCP server
disabling the codex-app-tools plugin (its MCP does time out after 10s at startup, but it's not the cause)
stopping CodexSandboxService
hiding ~/.ssh/config (the app auto-discovers SSH hosts and retries a remote codex every 10s with no retry limit — noisy in logs, but not the cause)

Reliable workaround: launch the app, wait until it hangs on the logo (~30s), then kill every codex.exe whose parent is ChatGPT.exe. The UI loads within seconds and Codex keeps working (the app respawns its app-server).

Note: the app spawns TWO codex.exe ~10s apart. Killing only the first one is not enough.

PowerShell:

Get-CimInstance Win32_Process -Filter "Name='codex.exe'" | Where-Object { (Get-Process -Id $.ParentProcessId -ErrorAction SilentlyContinue).ProcessName -eq 'ChatGPT' } | ForEach-Object { Stop-Process -Id $.ProcessId -Force }

(Diagnosed with help from Claude. Yes, really.)

@PrajnaFlow

@PrajnaFlow thank you, this worked for me also!

Same issue here, and it is not fixed in 26.928.2636.0.

Environment

Windows 11 Pro 10.0.26200 (x64), Microsoft Store package OpenAI.Codex_2p2nqsd0c76g0 (product 9PLM9XGG6VKS)
Affected: 26.924.2738.0 (since the 2026-09-26 update) and 26.928.2636.0 (installed 2026-09-30)
26.915.4065.0 worked with the same data
ChatGPT sign-in, business workspace account

Symptom
Window shows the loading spinner / ChatGPT logo forever. Main-process log never logs [startup][renderer] app routes mounted; after ~121–126 s it logs client.performance.span ... name=app_start outcome=failure reason=timeout. Renderer requests to the app-server (config/read, thread/read, thread/resume, configRequirements/read) hit mcp_request_timeout (pendingCount up to 10) while the app-server itself is up. Also seen: sa_server_request_failed ... "Workspace routing is unavailable".

What decides it (reproducible)

~/.codex/auth.json present at launch → hang.
auth.json moved aside before launch → routes mount in ~4–9 s and the computer-use native pipe starts; the app asks to sign in again (auth is NOT recreated automatically, unlike [Windows][Desktop][Auth] App hangs on infinite spinner when auth.json exists before process startup #48383).
On 26.928 the hang also happened right after signing in, in the same session (after the first launch had to install runtime 26.929.10730, which took ~3 min).

Ruled out: Windows Repair, Reset, uninstall/reinstall, reboot, a completely fresh CODEX_HOME (hangs as soon as the account is signed in), clearing the Chromium cache / Local Storage. Network is fine (chatgpt.com reachable; ChatGPT web works with the same account).

Workaround side effects

Killing the child codex.exe while the spinner shows ([Windows] Codex Desktop 26.924.1866.0 stuck on startup spinner until app-server codex.exe is terminated #48333) lets the UI load, but when done early the computer-use native pipe is never created ("Computer Use's Windows connection is unavailable"), and threads that were open may never be resumed.
After such launches, large threads (50–180 MB rollouts) often get markedStreaming=true although latestTurnStatus=completed (backend reports active_turn_present=false), so every follow-up goes to the queue (thread-queued-followups-changed) and is never sent.

Related: the Store update to 26.928 first failed with AppX error "Failure occurred in the PackagesInUseClosed state handler" because CodexSandboxService.OpenAI.Codex was still running; it only installed after stopping that service and rebooting.

Logs available on request.

@PrajnaFlow

@PrajnaFlow @R-S1978 Heads-up: killing codex.exe does clear the spinner, but several of us (and @ibrahimo-ops just above) saw follow-up messages get stuck in the queue afterwards and never send. Killing only the renderer processes clears the spinner too, and leaves the backend running, so sending keeps working:

Get-CimInstance Win32_Process -Filter "Name='ChatGPT.exe'" | Where-Object { $_.ExecutablePath -like '*\WindowsApps\OpenAI.Codex_*' -and $_.CommandLine -match '--type=renderer' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

@Swih

@Swih Thank you very much. I've now incorporated that into my script.

Windows desktop app stuck on loading screen after update — app_start bootstrap timeout after codex-home request (26.924.2738.0) #48463

Description

Description

Environment

Reproduction

Latest reproduction timestamp

Relevant desktop log

Additional network observations

Expected behavior

Actual behavior

Notes

Activity

github-actions commented on Sep 26, 2026

TheyCallMeJohn commented on Sep 26, 2026

Reyoonmath commented on Sep 26, 2026

Additional diagnostic report: reloading the main index.html renderer restored the UI

Symptom and impact

Attempts before the successful recovery

Observed recovery — target selection mattered

What the existing startup logs do and do not show

Request

hitonosan commented on Sep 27, 2026

moruku36 commented on Sep 27, 2026

Environment & Observation

bzc22580-design commented on Sep 27, 2026

xavierbarata commented on Sep 27, 2026

derectim commented on Sep 27, 2026

Rainman147 commented on Sep 27, 2026

Additional reproduction: renderer initialization replay and renderer reload recover the Windows startup spinner

Environment and impact

Observed failure

New diagnostic observation

Recovery on the original affected app

Doctor results after recovery

NinaManns commented on Sep 27, 2026

moruku36 commented on Sep 27, 2026

Swih commented on Sep 27, 2026

Root cause analysis (26.924.2738.0, Windows 11 26200), verified live via CDP on a stuck window

Suggested fixes (any one would do)

User-side workaround (no debug port needed)

4 remaining items

kanghyunmin-bot commented on Sep 28, 2026

Swih commented on Sep 28, 2026

luojinxiang6968-ctrl commented on Sep 28, 2026

Mr-enthalpy commented on Sep 28, 2026

CosmicsString commented on Sep 29, 2026

Environment

Symptom progression

Local-state observations

Swih commented on Sep 29, 2026

EOSOdinAdmin commented on Sep 29, 2026

NinaManns commented on Sep 29, 2026

September 29: renderer recovery confirmed; official fix still needed

R-S1978 commented on Sep 29, 2026

derectim commented on Sep 30, 2026

PrajnaFlow commented on Sep 30, 2026

R-S1978 commented on Sep 30, 2026

ibrahimo-ops commented on Sep 30, 2026

Swih commented on Sep 30, 2026

R-S1978 commented on Sep 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Additional diagnostic report: reloading the main `index.html` renderer restored the UI