Repository navigation
Windows desktop startup hangs with missing backend version; initialization handshake replay opens UI #49557
Description
Summary
Codex Desktop on Windows intermittently remains on its startup loading animation for minutes, with no application UI. The user reports recurrence after updates. Renderer reload recovered one failing launch. During another failing launch, replaying the existing initialization handshake delivered missing backend state and opened the UI without a reload.
Environment
- Diagnosed 2026-09-30, Windows x64.
- MSIX package: OpenAI.Codex 26.928.2636.0.
- Desktop client / installed app.asar package.json: 26.928.21956. The MSIX version is a separate metadata field.
- Bundled and running backend: codex-cli 0.159.2.
Reproduction and expected behavior
Cold-launch the registered desktop application. Intermittently, the startup animation remains indefinitely. The user associates recurrence with updates; the first post-update transition was not directly traced.
Expected: the app finishes initialization and displays its normal UI, or presents an actionable error.
Observed failing renderer state
- document.readyState=complete; body text length=0; startup loading component mounted.
- gatewayOAuthReadiness=loading, local backend version absent, renderer-side local host state=disconnected.
- Account authentication completed; feature access allowed; workspace roots and onboarding queries completed.
- Older host requests (including locale-info, inbox-items, list-automations, codex-home and get-global-state) remained pending. A new locale-info request returned status 200 immediately.
Diagnostic intervention
With user-authorized temporary loopback renderer debugging, we called the app's existing API once:
await window.electronBridge.sendMessageFromView({
type: "ready",
initializationOnly: true
});Actual initialization snapshots arrived. Renderer host state became connected, backend version became 0.159.2, readiness left loading, and the application shell appeared without reload or fabricated state.
Eight older requests remained pending after this replay and a subsequent normal ready message. A queue-based circular-wait explanation is therefore not established; those requests may have been dropped earlier.
Separately, a renderer reload recovered the UI and the user confirmed success. A later instrumented cold launch succeeded naturally, but instrumentation may affect timing. Debugging was stopped and the app relaunched through its registered Windows entry without debugging flags; both diagnostic ports were verified not listening.
Isolation
- Disabling the parent app-tools plugin eliminated its tools/list timeout, but the blank startup persisted. Setting restored.
- Rebuilding only Chromium Cache, Code Cache and GPUCache did not resolve the issue. Original caches restored; generated test caches retained separately.
- Approximately 15 GB RAM free; no recent Codex crash event found in Windows Application log; desktop log files empty.
- No chat, sign-in or installed package files changed.
Relevant installed code, inspected read-only
Inside app/resources/app.asar:
- webview/assets/app-initial-fd3c4b862660.js: r_c sends initializationOnly ready once on mount; cfc sends normal ready after routes mount. Startup indicator stays mounted while gateway readiness is loading, which occurs when the local backend version atom is absent.
- webview/assets/app-shared-a906948d8868.js: local host state starts disconnected/version undefined; initialization notifications set backend version.
- .vite/build/main-DkWgQSQe.js: initializationOnly ready sends current snapshots directly but does not mark the window ready; normal ready marks it ready; ordinary messages can be queued until window readiness.
- .vite/build/bootstrap-DvSEn4qy.js: sendInitializationSnapshot supplies a version snapshot only if the backend is already initialized.
Interpretation and requested investigation
Missing backend-version state explains the observed loading gate, and replay supplied that state and opened the gate. This strongly supports an initialization-delivery failure, but does not prove the initiating timing or exclude all contributors. Early readiness, missed delivery or incomplete host/window registration remain hypotheses. No permanent app-code fix has been applied.
Please trace renderer attachment, backend initialization and snapshot delivery; ensure current initialization state reaches the renderer even when backend initialization completes after attachment. A regression check should cover slow backend startup, cold launches and first launch after an update.
Related symptom reports: #48484, #48313, #48556. This report adds in-place initialization replay evidence; their initiating causes may differ.
No raw logs, chat content, account identifiers or credentials are included.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xrazai commentedon Sep 30, 2026
Additional diagnostics collected on 2026-09-30 for a recurring Windows startup spinner, shared at the affected user's request.
Environment
Reproduction and observed sequence
The user reports that normal app opening repeatedly stays on the loading animation. The desired behavior is a usable application interface without an external recovery shortcut.
Two inspected launches on September 30 (America/Sao_Paulo, UTC-03):
app_startis recorded before that launch ends.app_start outcome=successat 07:31:49.This confirms that backend/authentication readiness and initial main-frame load can occur without a usable interface. Reload recovery is observed; a permanent fix has not been established.
Read-only installation/environment checks
app/ChatGPT.exe(73 blocks) andapp/resources/app.asar(8253 blocks). This checks those two core files, not every installed file.Caveats
The workaround directly starts the EXE. That launch logs
no-package-identityand an unavailable updater. Normal packaged launches also hang, so this side effect is not established as the original cause. The Artifact Session Windows transport warning andfs/readFile requires an environmentIdalso appear in successful startup sequences and are not decisive.Existing logs support a frontend initialization/state-delivery problem but cannot distinguish its initiating race from persistent local state. Please advise what additional supported diagnostics would help isolate it.
No raw logs, conversation content, personal paths, account identifiers or credentials are included.
Related reports reviewed
At the affected user's request, this index adds 36 related issues whose bodies or diagnostic comments were reviewed. It provides links and the observed relationship; matching symptoms alone do not establish a shared root cause. The index includes the potential duplicates suggested earlier in this thread.
Closest matches: initialization state, reload or backend reconnection
Additional Windows startup/reopen reports with the same visible symptom
Related delivery mechanism and older Windows presentation failures
The closest reports describe backend/authentication readiness without a usable renderer, followed by recovery after state replay, renderer reload or backend reconnection. Additional reports reproduce the visible hang across Windows 10/11 and multiple 26.924/26.928 builds. Please consider consolidating the applicable reports, checking initialization snapshot/response delivery under cold-start timing, and providing a supported recovery path and fix status. The older presentation cases are listed separately because their failure stage may differ.
This is a reference index, not an assertion that every issue is a duplicate or that the reporters represent 36 distinct affected installations.
superNos commentedon Oct 3, 2026
The same question, marked