Windows desktop app stuck on infinite loading spinner – renderer alive, app://-/index.html route never resolves

Description

The Codex Windows desktop app opens successfully but remains permanently stuck on the loading spinner.

The browser version of ChatGPT works normally.

Environment

Windows 11 25H2
Build: 26200.9457
OpenAI Codex package: OpenAI.Codex
Desktop version: 26.924.2738.0
Package family: OpenAI.Codex_2p2nqsd0c76g0

Expected behavior

The Codex desktop UI should finish loading and show the normal application interface / composer.

Actual behavior

The window opens, but remains indefinitely on the loading spinner.

The app does not crash and the backend continues running.

Diagnostics

The following components start successfully:

ChatGPT.exe main process
Chromium renderer processes
GPU process
Network service
Storage service
codex.exe app-server

Authentication works and backend communication is active.

The Codex models endpoint returns HTTP 200.

The MSIX/AppX application activation succeeds.

Chromium / Electron debugging

I launched the application with:

--enable-logging --v=1 --remote-debugging-port=9222

The DevTools endpoint works on:

127.0.0.1:9222

The main renderer target is:

app://-/index.html

A direct WebSocket connection to the Chrome DevTools Protocol for this renderer succeeds (STATE: Open).

The renderer repeatedly reports:

Matched leaf route at location "/" does not have an element or Component.
This means it will render an with a null value by default resulting in an "empty" page.

Source:

app://-/assets/app-initial-ff48311587c5.js

The renderer continues making backend requests after this warning, including requests for:

account information
user settings
sites/access
task list
usage
onboarding context
automations

No fatal JavaScript exception has been found in the Electron renderer log so far.

Troubleshooting already performed

Reinstalled the desktop application
Windows Repair / Reset
Tested another network / mobile hotspot
Checked WebView2
Tested GPU-disabled launch
Tested with a clean Chromium/Electron profile
Isolated Codex thread history
Isolated session data
Isolated state_5.sqlite
Isolated .codex-global-state.json
Verified SQLite integrity
Tested without plugin/temp state
Checked AppModel Runtime / TWinUI activation
Checked Windows Defender Controlled Folder Access

Controlled Folder Access had previously blocked some Codex helper/sandbox processes. Those permissions were corrected and Codex CLI sandbox/write tests now succeed. The desktop spinner issue remains unchanged.

Logs available

I can provide, after redacting sensitive information:

Electron debug log
Codex app-server logs
Windows Event Viewer logs
process trees / command lines
AppModel / TWinUI activation logs
Codex session transcripts
screenshots

I cannot generate an in-app feedback Session ID because the desktop app never reaches the composer.

Please let me know which additional diagnostic information would be useful.

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

Windows desktop app stuck on loading screen after update — app_start bootstrap timeout after codex-home request (26.924.2738.0) #48463
[Windows 26.924.2738.0] Startup spinner recovers after reloading main index.html, not detached window #48487
Windows desktop stuck on startup spinner; Remote still works #48484
[Windows 26.924] Every cold startup stalls on Loading; restarting only app-server restores UI #48466
[Windows][26.924.2738.0] Repeated startup/loading hang; Event ID 1002 #48457

Powered by Codex Action

Confirming this is the same build (26.924.2738.0) and the same symptom. Adding the one piece of evidence I have not seen posted yet, which points at a specific cause.

Reproduction pattern

This is not a permanent hang. Any change to local app state produces exactly one working launch, and every launch after that hangs again. Observed with all of:

Full clean reinstall (removed the package plus ~2.7 GB of residue, then reinstalled from the Store) -> first 2 launches fine, 3rd onward hangs
Settings > Apps > Installed apps > ChatGPT > Advanced options > Reset -> 1 launch fine, 2nd onward hangs
Renaming %USERPROFILE%\.codex to a fresh directory -> 1 launch fine, 2nd onward hangs
End Task on all ChatGPT.exe and codex.exe processes -> no effect

On the working launch the sidebar, projects, conversation history and composer all render normally. On the failing launches the sign-in window never appears at all.

The window that appears instead of the mascot overlay

On a working launch the app registers its second window as an avatar overlay:

[window-manager] window ready-to-show appearance=primary      webContentsId=1 windowId=1
[window-manager] window ready-to-show appearance=avatarOverlay webContentsId=2 windowId=2

On every failing launch, the same slot (webContentsId=2, windowId=2) is registered as detached instead:

[window-manager] window ready-to-show appearance=primary      webContentsId=1 windowId=1
[window-manager] window ready-to-show appearance=detached     webContentsId=2 windowId=2
[window-manager] window main frame finished load appearance=detached webContentsId=2 windowId=2

This appears deterministically ~4.7 s after startup, and nothing in the log requests it. The detached window loads a page whose root route has no matching component, so the renderer logs the "empty page" warning:

Matched leaf route at location "/" does not have an element or Component.
This means it will render an <Outlet /> with a null value by default resulting in an "empty" page.

It then steals focus and the boot never completes

The primary window is still focused and visible right up to 108 ms before the detached window is created. After that, the last line the app ever writes is:

[bundled-plugins] bundled_plugins_reconcile_skipped_features_unavailable reason=focus

reason=focus means the plugin reconciliation was cancelled because the window was not focused. From that point the app emits no further log output for 5+ minutes and the interface never mounts. My hypothesis is that the bootstrap awaits that reconciliation, so the focus loss leaves it pending forever, with no timeout or error boundary.

Log excerpt from a failing launch

From 20 lines before the first appearance=detached entry, through the window creation. Personal paths and identifiers redacted:

2026-09-26T19:45:41.960Z info [electron-message-handler] Concurrent reasoning summaries feature override resolved featureOverride=true rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true
2026-09-26T19:45:41.978Z info [electron-message-handler] Codex runtime config selected artifact=codex-primary-runtime rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true
2026-09-26T19:45:42.011Z info [remote-connections/window-context] refresh_remote_control_started previousConnectionCount=0
2026-09-26T19:45:42.011Z info [remote-connections/window-context] reconcile_completed creationFailureCount=0 nextConnectionCount=0 previousConnectionCount=0
2026-09-26T19:45:42.012Z info [electron-message-handler] [remote-connections/bootstrap] shared_object_synced connectionCount=0 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true
2026-09-26T19:45:42.012Z info [electron-message-handler] [desktop-notifications] service starting rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true
2026-09-26T19:45:42.023Z info [electron-fetch-handler] codex-home request hostId=undefined
2026-09-26T19:45:42.053Z info [AppServerConnection] response_routed method=experimentalFeature/list originWebcontentsId=1 queueWaitMs=0
2026-09-26T19:45:43.228Z info [AppServerConnection] response_routed method=configRequirements/read originWebcontentsId=1 queueWaitMs=0
2026-09-26T19:45:43.233Z info [AppServerConnection] response_routed method=config/read originWebcontentsId=1 queueWaitMs=0
2026-09-26T19:45:43.234Z info [AppServerConnection] response_routed method=windowsSandbox/readiness originWebcontentsId=1 queueWaitMs=0
2026-09-26T19:45:43.256Z info [remote-connections/window-context] reconcile_completed creationFailureCount=0 nextConnectionCount=0 previousConnectionCount=0
2026-09-26T19:45:43.258Z info [electron-message-handler] [remote-connections/bootstrap] shared_object_synced connectionCount=0 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true
2026-09-26T19:45:43.491Z info [electron-message-handler] chatgpt_pubsub_transport_opened rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true topicCount=1 windowFocused=true
2026-09-26T19:45:43.515Z info [electron-message-handler] chatgpt_pubsub_topic_subscribed rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true topicId=resource-updates
2026-09-26T19:45:44.057Z info [IpcRouter] I am the router
2026-09-26T19:45:44.060Z warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-09-26T19:45:44.060Z warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-09-26T19:45:44.168Z info [window-manager] window ready-to-show appearance=detached hostId=local startupElapsedMs=133 webContentsId=2 windowId=2
2026-09-26T19:45:44.172Z info [window-manager] window main frame finished load appearance=detached hostId=local startupElapsedMs=137 webContentsId=2 windowId=2

A/B on auth.json

Related to #48383. I tested moving %USERPROFILE%\.codex\auth.json aside before launch, same build:

Run	auth.json at process start	Result
Control	present	infinite spinner
Test	moved aside	UI rendered fully (7.67% non-background pixels)

However I do not want to overstate this: on the next launch, using the exact same procedure, it hung again, even though the app had recreated auth.json in the meantime. So in my case it produced one good launch and then reverted, and I could not make it reliable. Posting it only so others can retest on this build.

Ruled out on this machine

Package integrity OK; binary integrity OK (SHA-256 of codex.exe, rg.exe, codex-command-runner.exe, codex-code-mode-host.exe, codex-windows-sandbox-setup.exe all match the files under C:\Program Files\WindowsApps)
Auth OK (token valid, Plus active); chatgpt.com, auth.openai.com, api.openai.com, cdn.oaistatic.com all HTTP 200
No proxy (WinINET ProxyEnable=0x0, no ProxyServer, no AutoConfigURL, no proxy env vars); only Windows Defender installed; no third-party network filter driver active
Machine: Windows 11 Pro 25H2 build 26200.9168, x64, 31 GB RAM, 380 GB free, NTFS
codex.exe core (0.158.0-alpha.2.1) stays alive, healthy and answering JSON-RPC the entire time the UI is hung
Windows sandbox healthy: CodexSandboxService.OpenAI.Codex running, CodexSandboxOffline/CodexSandboxOnline enabled, windowsSandbox/readiness returns {"status":"ready"}
All plugins valid: 62 in the synced marketplace plus 15 cached, every .codex-plugin/plugin.json parses
config.toml contains no approval_policy key

One note for triage: this error also appears on launches that work, so I do not think it is causal:

[electron-message-handler] Request failed conversationId=none durationMs=1
error={"code":-32603,"message":"The system cannot find the path specified. (os error 3)"}
method=fs/readFile pendingCountAfter=1 timeoutMs=0

Ask

Could someone confirm whether webContentsId=2 is supposed to be registered as avatarOverlay rather than detached during startup, and whether the boot path should survive losing focus? A timeout or a recoverable error on bundled_plugins_reconcile_skipped_features_unavailable would also turn this from a silent hang into something actionable.

Not offering a workaround, since I could not make one reliable. Happy to provide more log excerpts from this build.

Support provided additional diagnostics suggesting a possible startup focus/window-state issue on the same build.
On failing launches, a second window is reportedly created as appearance=detached instead of appearance=avatarOverlay, followed by bundled_plugins_reconcile_skipped_features_unavailable reason=focus.
My machine independently shows the same two renderer targets:
app://-/index.html
app://-/detached-window.html?initialRoute=%2Fdetached-window
Reloading the main index.html renderer via CDP restores the UI for the current instance, but the problem returns after a full relaunch.
This may be related to focus/window initialization, although I cannot confirm causality.

I can confirm the same issue on the same Windows desktop build, with one additional account-specific reproduction pattern that may help triage.

Environment

Windows 11 x64, build 26200
Desktop package: OpenAI.Codex 26.924.2738.0
Embedded Codex runtime observed: 0.158.0-alpha.2.1
Main account: ChatGPT Pro

Reproduction

With my main Pro account:

Reset/remove the Desktop MSIX profile state under:
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex
Launch Desktop -> works normally once
Close Desktop normally
Launch Desktop again -> infinite spinner
Reset/remove that profile again -> next launch works once again
Close/reopen -> spinner returns

This is reproducible.

Account-specific A/B

On the exact same PC, same Desktop installation, same network:

Newly created Free OpenAI account -> Desktop loads normally
Main Pro account -> spinner
Switching from Free back to Pro can temporarily make Pro work for one launch
Closing and reopening returns the Pro account to the spinner

ChatGPT Web and Codex Cloud both work normally with the affected Pro account.

Isolation already performed

The issue still reproduces after:

Full uninstall/reinstall from Microsoft Store
Windows App Reset / clean MSIX profile
Mobile hotspot instead of home network
Removing custom config.toml
WSL agent environment
Windows-native agent environment
Fresh local authentication
Switching accounts

codex doctor confirmed:

ChatGPT auth configured
HTTP provider reachability OK
WebSocket handshake OK (HTTP 101 Switching Protocols)
no proxy configured

Sandbox diagnostics

Windows sandbox setup appears healthy.

Relevant sanitized sandbox log results:

WFP setup succeeded for CodexSandboxOffline with 12 installed filters
setup provisioning binary completed
read ACL run completed
setup refresh: processed 0 write roots (read roots delegated); errors=[]
setup binary completed

No 1385, access denied, panic, exception, or sandbox setup failure was found.

Session / plaintext logging behavior

On failing launches:

no new Codex session transcript appears to be created under %USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\archived_sessions has no relevant new entry
log_dir was explicitly configured
RUST_LOG=debug is confirmed in the environment
nevertheless %USERPROFILE%\.codex\log remains empty; no codex-tui.log is produced
I cannot generate a /feedback session ID because the UI never reaches the composer

OpenAI support indicated that this exhausts the documented Desktop diagnostics and suggested filing/adding this to the engineering tracker.

The strongest signal on my machine is that clearing Desktop app state gives exactly one successful Pro launch, then the next launch hangs again, while a fresh Free account works on the same installation.

Small correction to my previous comment after another reproduction attempt:

The MSIX profile reset is not 100% reliable on my machine. It has repeatedly produced the pattern “one successful launch, then spinner on the next launch”, but on a later attempt, deleting the same Desktop profile and relaunching still went directly to the spinner.

So please treat “profile reset -> one good launch” as a frequent workaround pattern, not a guaranteed deterministic result.

The stronger/reliable A/B observations remain:

same PC / same app / same network
fresh Free account can load normally
affected Pro account repeatedly returns to the startup spinner
switching accounts can temporarily restore the Pro UI
web ChatGPT and Codex Cloud work normally
issue reproduces without custom config.toml and in both WSL and Windows-native agent modes
sandbox setup logs remain clean (errors=[])
failing launch still produces no useful plaintext runtime log despite log_dir + RUST_LOG=debug

The focus/window-state evidence already posted in this issue (second window becoming appearance=detached instead of avatarOverlay) looks especially relevant to the behavior I am seeing as well.

Temporary Windows workaround (tested on 26.924.2738.0)

I can confirm that recreating the primary ChatGPT renderer works as a temporary workaround for the startup spinner on my machine.

This is consistent with the renderer-recreation workaround discussed in related issue #48333. In my case, the following launcher works:

@echo off
setlocal EnableExtensions

title ChatGPT / Codex Windows Startup Spinner Workaround

echo.
echo ===================================================
echo   ChatGPT / Codex Windows Startup Spinner Workaround
echo ===================================================
echo.
echo This temporary workaround:
echo   1. closes ChatGPT / Codex
echo   2. launches the desktop app
echo   3. waits for the primary renderer to initialize
echo   4. restarts only that renderer
echo.
echo It does NOT delete your account, auth data, chats, or config files.
echo.

echo [1/4] Closing existing ChatGPT / Codex processes...
taskkill /F /IM ChatGPT.exe >nul 2>&1
taskkill /F /IM codex.exe >nul 2>&1
timeout /t 2 /nobreak >nul

echo [2/4] Launching ChatGPT / Codex...
start "" "codex:"

echo [3/4] Waiting for the primary renderer...
timeout /t 8 /nobreak >nul

echo [4/4] Restarting the primary renderer...
powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "$r = Get-CimInstance Win32_Process -Filter \"Name='ChatGPT.exe'\" -ErrorAction SilentlyContinue | Where-Object { $_.CommandLine -match '--type=renderer' -and $_.CommandLine -match '--renderer-client-id=(\d+)' } | ForEach-Object { [PSCustomObject]@{ PID=$_.ProcessId; RID=[int]([regex]::Match($_.CommandLine,'--renderer-client-id=(\d+)').Groups[1].Value) } } | Sort-Object RID | Select-Object -First 1; if ($r) { Write-Host ('Primary renderer found: PID ' + $r.PID + ' / client-id ' + $r.RID); Stop-Process -Id $r.PID -Force -ErrorAction Stop; exit 0 } else { Write-Host 'No ChatGPT renderer found.'; exit 2 }"

if errorlevel 2 (
    echo.
    echo ERROR: The primary renderer could not be identified.
    echo ChatGPT remains open and no local data was modified.
    echo.
    pause
    exit /b 2
)

echo.
echo The primary renderer was restarted.
echo ChatGPT should recreate it automatically and finish loading.
echo Please wait about 5 to 10 seconds.
echo.

timeout /t 8 /nobreak >nul

echo Done.
pause

endlocal
exit /b 0

This does not reset the MSIX profile and does not delete auth.json or config.toml. It only forces the primary renderer to be recreated.

This is a temporary workaround, not a fix.

Another Windows desktop case on September 27, 2026 (KST): after an OpenAI.Codex Microsoft Store update, the app opens to a blank pale window with a centered loading spinner indefinitely. The window still responds to right-click (shows “Select All”), but the sign-in screen and main UI never appear. ChatGPT Work in the browser works on the same PC. Windows Reliability Monitor shows the OpenAI.Codex package update succeeded and no Codex application crash entry at the time of reproduction. We have tried restarting Windows, uninstalling/reinstalling the app, Windows app Repair and Reset, and wsreset.exe; the spinner persists. The exact app package version and root cause are not yet confirmed. This report is intended as an additional reproduction, not a claim that the renderer route issue identified above is the same cause.

What works for me is: launch the app -> open Task Manager -> kill the first Codex child process.
That's it. Wait about 2-5 seconds and kill another one. When you see the OpenAI logo instead of the infinity loading circle, it worked.

Same symptom on Windows 11 (26200) with OpenAI.Codex 26.924.2738.0 / app-server 0.158.0-alpha.2.1. Two findings that may help:

1. Startup race, reproducible workaround. In every stuck run the main-process log stops right after bundled_plugins_reconcile_completed and never logs [startup][renderer] app routes mounted; every run that did succeed had an app-server reconnect/restart after the renderer loaded. Forcing that reconnect unsticks the UI within seconds, with the user's original state files untouched:

While the spinner is showing, Stop-Process the codex.exe child of ChatGPT.exe (the bundled app-server). The app relaunches it -> Transport start success connectionId=2 -> app routes mounted after 95093ms. Reproduced 3 times.
Resetting .codex-global-state.json, the renderer Local Storage, config.toml, DNS, proxy settings, or reinstalling did not change anything.
The renderer console shows the same Matched leaf route at location "/" does not have an element or Component warning as in this issue.

2. Separate aggravating factor: VS Code extension. The VS Code extension openai.chatgpt 26.917.62051 hosts the \\.\pipe\codex-ipc hub. With VS Code running, that pipe can end up permanently ERROR_PIPE_BUSY (WaitNamedPipe 5 s -> ERROR_SEM_TIMEOUT), and the desktop app then logs [IpcClient] Initialize failed errorMessage=timeout every few seconds. Killing that VS Code extension host (or disabling the extension) clears it; the desktop app then hosts the pipe itself.

Happy to share the desktop logs privately.

AI-Context: Session-Ref: chatgpt-startup-0928 · Device: windows-workstation · User-Role: owner · Endpoint: claude-desktop · Workspace: woonger/homelab-infra · Quota-Band: unknown
AI-Execution: Provider: anthropic · Router: n/a · Route-Alias: n/a · Model-Source: self-reported · Role: implementer · Environment: local-workstation
AI-Tool: claude-code · Model: claude-fable-5-1 · Mode: unknown · Session: chatgpt-startup-0928 · Date: 2026-09-28

Update from the same reporter (September 28, KST): a second, separate Windows desktop PC at the office also became unusable with the same blank window / endless centered spinner immediately after updating the ChatGPT/Codex desktop app. This broadens the reproduction beyond the original PC. I have not yet collected the second PC's exact package version or logs, so I am not claiming the same internal root cause.

What works for me is: launch the app -> open Task Manager -> kill the first Codex child process. That's it. Wait about 2-5 seconds and kill another one. When you see the OpenAI logo instead of the infinity loading circle, it worked.

This helped me. Was getting infinite spinner even after reboot. Killed the first process. Didn't have to kill another one though, just a few seconds after killing the first Codex process the app completed it's startup and i have a working window. Version 26.924.22138

I can independently reproduce this issue on Windows, and I have one additional data point that may help isolate the cause: the behavior appears to be account-dependent on the exact same installation.

Environment

Windows 10 Pro 22H2 (Build 19045.6466)
Codex Windows desktop app: 26.924.2738.0
Codex CLI / Doctor: 0.158.0-alpha.2.1
ChatGPT Plus account

Controlled account A/B test

I tested two ChatGPT accounts using the same PC, same Windows installation, same Codex installation, and same network:

I isolated both the existing Electron web profile and .codex state.
The app immediately reached the Sign in screen.
I signed in with a second Free ChatGPT account.
Codex loaded normally, Home/Projects worked, a new conversation worked, and the app continued to work after closing and reopening it.
I then switched to my main ChatGPT Plus account in the same clean environment.
The app returned to the infinite Loading screen.

So in my test:

Same machine + same app + same network + Free account = works

Same machine + same app + same network + Plus account = infinite Loading

Additional diagnostics

codex doctor reports no failures. Authentication is configured correctly, the state databases pass integrity checks, thread inventory is consistent, provider endpoints are reachable, the WebSocket connection succeeds with HTTP 101, and the desktop assets CDN is reachable.

During a failed launch, the desktop logs show that:

the app-server starts and initializes successfully;
ChatGPT authentication succeeds;
an authenticated account is present;
the Electron window reaches ready-to-show;
the Codex primary runtime/plugin reconciliation runs;
backend requests continue succeeding while the UI remains indefinitely on Loading.

I left one failed session running for approximately one hour. The backend remained responsive during that period; the UI never progressed past the Loading screen.

I also tested isolating config.toml. After doing so, the Plus account successfully opened once, including Projects and Recents, but after closing and reopening the app the infinite Loading behavior returned.

A separate Free account consistently survived a normal close/reopen test.

This makes the issue look less like a basic Windows/network/authentication failure and more like something triggered during account-specific desktop initialization, runtime/plugin reconciliation, entitlement/config synchronization, or frontend state restoration.

I also have the full codex doctor --json output and desktop logs from the failed ~1-hour session if they would be useful for debugging.

Additional A/B log comparison found another account-specific difference that may be useful for triage.

On the affected Plus account, the desktop logs repeatedly return HTTP 432 with:

Workspace routing is unavailable

for requests including:

/wham/tasks/list?limit=20&task_filter=current
/wham/usage

These failures repeat while the UI remains stuck on the Loading spinner.

I searched the working Free-account log from the same PC / same Codex installation / same network and did not find the same Workspace routing is unavailable / HTTP 432 failures.

At the same time, basic authentication on the affected Plus account succeeds: the app-server initializes, account/read / auth checks succeed, an authenticated ChatGPT account is present, the Electron window reaches ready-to-show, and backend requests continue to be serviced while the UI remains stuck.

I do not want to overstate causality — HTTP 432 may be a symptom rather than the root cause — but it is currently the clearest account-specific divergence in my Free-vs-Plus startup logs. It may point toward workspace/account routing, entitlement initialization, or related frontend bootstrap state rather than a basic Windows, network, or authentication failure.

Update from the same reporter — still reproducible on 2026-09-30 (Asia/Seoul) after updating and fully quitting/relaunching the app.

Current environment (verified locally)

Windows 11 Pro 25H2, build 26200.9550, x64.
Installed Microsoft Store package: OpenAI.Codex 26.928.2636.0.
The actual codex.exe used by the running desktop app reports codex-cli 0.159.2.
31.1 GiB usable RAM; AMD Ryzen 7 7800X3D; NVIDIA RTX 4080 and AMD integrated graphics.

Reproduction and recovery

Launch the signed-in Windows desktop app.
The window remains on the loading spinner.
The user has already installed today's available updates and fully terminated/restarted the app; the problem keeps returning.
Ending one specific ChatGPT.exe --type=renderer process in Task Manager allows the app to finish loading for that launch.
Ending other, lower-memory ChatGPT child processes did not help.
This renderer-only recovery was repeated by the user. It is temporary: a subsequent full launch can hang again.

The screenshot from the affected run identifies the terminated process as a renderer (PID 9132 in that run; the PID is not stable). This is not a report that killing the child codex.exe app-server has been tested on this machine.

Startup timeline from the affected machine

The desktop logs show the backend initializing and the primary window loading, followed by a long gap before main routes mount. For one launch, elapsed wall time from the first line to routes mounting is 521.154 seconds (8 min 41 sec):

2026-09-30T09:44:39.907Z info Launching app agentRunId=null allowDebugMenu=false allowDevtools=false allowInspectElement=false buildFlavor=prod enableSparkle=false enableUpdater=true nodeEnv=undefined packaged=true platform=win32
2026-09-30T09:44:40.297Z info [AppServerConnection] Codex CLI initialized
2026-09-30T09:44:40.349Z info [window-manager] window main frame finished load appearance=primary hostId=local startupElapsedMs=375 webContentsId=1 windowId=1
2026-09-30T09:44:41.853Z info [electron-message-handler] [statsig-refresh-diagnostics] React root render requested rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true windowType=electron
2026-09-30T09:44:45.516Z info [window-manager] window main frame finished load appearance=detached hostId=local startupElapsedMs=241 webContentsId=2 windowId=2
2026-09-30T09:53:17.518Z info [electron-message-handler] [statsig-refresh-diagnostics] React root render requested rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true windowType=electron
2026-09-30T09:53:21.061Z info [electron-message-handler] [startup][renderer] app routes mounted after 5221ms rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true

All timestamps above are UTC (18:44–18:53 KST). The short after 5221ms value is the later renderer startup measurement; it is not the full time since app launch. Other inspected launches had approximately 32, 109, 86, and 99 seconds between process launch and first primary routes mount. The exact process-termination time is not recorded in the provided excerpt, so these are observed timings, not a controlled measurement of kill-to-recovery latency.

Repeated ResizeObserver loop completed with undelivered notifications. errors also appear after routes have mounted. I am reporting them as a secondary observation, not claiming they cause the startup hang.

This appears consistent with the renderer-recreation workaround already discussed here and the startup-ordering observations in #48896, but a shared code-level root cause has not been confirmed.

Please track this as a reproduction on the newer 26.928.2636.0 / 0.159.2 combination and advise whether there is a fixed build or a supported way to reload only the desktop UI. The user needs a durable fix; update/full-restart guidance has already been tried. Only selected diagnostic lines are included; raw logs, credentials, and private conversation content are omitted.

The recurring Windows startup-spinner problem is still reproducible on OpenAI.Codex package 26.928.2636.0 as of September 30, 2026. Updating did not establish reliable startup. The app can open on one attempt and then remain stuck on loading on a later normal launch.

Please prioritize this issue and provide a supported recovery procedure or a verified fixed version. Reliable repeated launches into a responsive interface are needed; a single successful opening is not sufficient.

This comment intentionally contains no account, billing, conversation, or local diagnostic information.

Hi maintainers — following up because this issue is still blocking Codex Desktop for me on a ChatGPT Plus account.

The app remains stuck on infinite Loading, and the errors observed include HTTP 432 and Workspace routing is unavailable.

This is also causing real loss of productive work time, as a paid Plus feature I rely on remains unusable. Could you please confirm whether the root cause has been identified, or whether there is a build/fix we can test?

Given the duration and impact of the outage, I’d also appreciate clarification on whether affected Plus users will receive any service credit, usage reset, or other compensation for the period during which Codex Desktop has been unavailable.

If additional logs or diagnostics from my machine would help, I'm happy to provide them.

Thanks.

Update from the affected Windows / ChatGPT Plus account (October 10, 2026):

The desktop app is now opening normally on OpenAI.Codex 26.1007.2314.0. I was able to send a message and receive a response, then fully close and reopen the app successfully without the previous infinite Loading screen.

This is a preliminary positive result, not a confirmed resolution. I will actively use the app for work over the next three days and monitor for any recurrence of the loading hang, HTTP 432, or Workspace routing is unavailable. If the problem returns, I will report the reproduction details here. If it remains stable throughout the test period, I will post another update confirming the observed resolution on my setup.

Please keep the issue open for now; this test does not establish a general fix or root cause. My earlier question about potential service credit or compensation for lost productive time also remains outstanding.

Thanks.

Navigation Menu

Repository navigation

Windows desktop app stuck on infinite loading spinner – renderer alive, app://-/index.html route never resolves #48522

Description

Environment

Expected behavior

Actual behavior

Diagnostics

Chromium / Electron debugging

Troubleshooting already performed

Logs available

Reproduction pattern

The window that appears instead of the mascot overlay

It then steals focus and the boot never completes

Log excerpt from a failing launch

A/B on auth.json

Ruled out on this machine

Ask

Environment

Reproduction

Account-specific A/B

Isolation already performed

Sandbox diagnostics

Session / plaintext logging behavior

Temporary Windows workaround (tested on 26.924.2738.0)

Environment

Controlled account A/B test

Additional diagnostics

Current environment (verified locally)

Reproduction and recovery

Startup timeline from the affected machine

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows desktop app stuck on infinite loading spinner – renderer alive, app://-/index.html route never resolves #48522

Description

Description

Environment

Expected behavior

Actual behavior

Diagnostics

Chromium / Electron debugging

Troubleshooting already performed

Logs available

Activity

github-actions commented on Sep 26, 2026

netutinho commented on Sep 26, 2026

Reproduction pattern

The window that appears instead of the mascot overlay

It then steals focus and the boot never completes

Log excerpt from a failing launch

A/B on auth.json

Ruled out on this machine

Ask

alexstollo292-ui commented on Sep 26, 2026

Sylvian commented on Sep 26, 2026

Environment

Reproduction

Account-specific A/B

Isolation already performed

Sandbox diagnostics

Session / plaintext logging behavior

Sylvian commented on Sep 26, 2026

Sylvian commented on Sep 26, 2026

Temporary Windows workaround (tested on 26.924.2738.0)

onlyasuka8395-cell commented on Sep 27, 2026

netutinho commented on Sep 27, 2026

woonger commented on Sep 27, 2026

onlyasuka8395-cell commented on Sep 28, 2026

ashelley commented on Sep 28, 2026

ahmedmagdy193-creator commented on Sep 28, 2026

Environment

Controlled account A/B test

Additional diagnostics

ahmedmagdy193-creator commented on Sep 28, 2026

onlyasuka8395-cell commented on Sep 30, 2026

Current environment (verified locally)

Reproduction and recovery

Startup timeline from the affected machine

Gavse commented on Sep 30, 2026

ahmedmagdy193-creator commented on Sep 30, 2026

ahmedmagdy193-creator commented on Oct 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions