Repository navigation
Windows Desktop app stuck on loading due to initialization handshake race condition #49237
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT Desktop Build 11645 Commit: 2e782921 App Server: 0.158.0-alpha.2.1
What subscription do you have?
ChatGPT Prolite
What platform is your computer?
Windows x64 Windows 11
What issue are you seeing?
The Windows desktop client intermittently gets stuck on the loading screen during startup.
Authentication succeeds, but the initialization readiness check remains stuck in loading state indefinitely.
The issue appears to be a race condition during the initialization handshake between the renderer process and the main process.
Observed behavior:
- App launches normally.
- User authentication is already completed.
- Renderer remains waiting for initialization state.
- UI never reaches the main chat interface.
The issue can be resolved immediately by triggering initialization again or restarting the app.
Possible cause:
The renderer may miss a one-time initialization response/event because the listener is not registered before the main process sends the response.
Possible sequence:
Main process starts
-> sends initialization response
-> renderer listener not ready
-> response lost
-> renderer remains loading forever
Environment:
- Windows x64
- Build: 11645
- Commit: 2e782921
- App Server: 0.158.0-alpha.2.1
Expected behavior:
Initialization should recover automatically through state synchronization, timeout handling, or retry logic.
Please investigate the initialization lifecycle and IPC handshake between renderer and main process.
What steps can reproduce the bug?
- Fully exit the Windows desktop app (make sure no background process remains).
- Launch the app again from a cold start.
- Wait for the application initialization process to complete.
- In affected launches, authentication succeeds but the app remains stuck on the loading screen.
- The initialization readiness check does not progress and the main chat interface never appears.
- Trigger the initialization process again (or restart the app).
- The app starts normally after the retry.
The issue is intermittent, but it happens repeatedly on cold launches.
Environment:
- Windows x64
- Build: 11645
- Commit: 2e782921
- App Server: 0.158.0-alpha.2.1
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Sep 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ilhancakmak06 commentedon Sep 29, 2026
I can also reproduce this startup hang on desktop app 26.928.20755 / app-server 0.159.0 (Windows 11). I posted sanitized measurements and the Task Manager app-server restart workaround in #49240: #49240 (comment)
The initial app-server handshake and account lookup succeed within milliseconds, yet the shell remains loading until the app-server connection is recreated. The latest cold launch timed out after 177.791 s wall time (55.709 s backgrounded). Switching the default browser to Edge did not fix it. A separate Norton HTTP-decoding issue was isolated and fixed, but this startup hang persists.
A missed readiness notification/state synchronization race is a plausible explanation; the logs do not directly establish which event or startup request is lost. Please correlate this reproduction with #49240 and investigate recovery of the initial renderer/main/app-server state. A feedback-upload session ID is not available yet.
eunchan0324 commentedon Oct 1, 2026
Additional reproduction on Windows x64, Codex Desktop package 26.928.3736.0.
Observations
{ type: "ready", initializationOnly: true }recovered the UI. After recovery, both existing conversations and new chats could send messages and receive replies.Reproduction sequence
This supports investigating readiness/state synchronization, but does not establish which event or request is lost, or prove that every similar report has the same cause. Please consider checking listener registration versus initialization delivery and an idempotent readiness-state replay/retry.
The diagnostic debugger was loopback-only and closed after testing. No installed application code was patched. No credentials, configuration dumps, conversation contents, or backup files are attached.
If these observations help with the fix, a reference to this comment in the related issue or pull request would be appreciated so the diagnostic contribution remains traceable.