Repository navigation
[Windows][26.924.20706] Endless startup spinner after update; runtime logs awaiting-framework with undefined bundle version #48377
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Desktop log release: 26.924.20706; Windows Store package OpenAI.Codex: 26.924.1866.0. About dialog is inaccessible because startup never finishes.
What subscription do you have?
ChatGPT sign-in; exact subscription tier not specified in this report.
What platform is your computer?
Windows, OS version 10.0.26200, x64 (from desktop logs).
What issue are you seeing?
After updating the Windows desktop app on 2026-09-26, the window stays blank/light with a loading spinner for more than 10 minutes. The normal interface never becomes usable. The problem persists across app restarts.
The installed Store package is OpenAI.Codex, version 26.924.1866.0, with Status: Ok. Desktop logs report release 26.924.20706 and bundled app-server 0.158.0-alpha.2.
Relevant startup logs (personal paths and identifiers redacted)
2026-09-26T06:16:39.683Z info [install-primary-runtime] primary_runtime_selection architecture=x64 buildFlavor=prod desiredBundleVersion=undefined frameworkEligible=true frameworkEnabled=true osRelease=10.0.26200 reason=awaiting-framework runtimeRoot=<USERPROFILE>\.cache\codex-runtimes\codex-primary-runtime runtimeSource=archive
2026-09-26T06:16:43.924Z info [install-primary-runtime] primary_runtime_selection architecture=x64 buildFlavor=prod desiredBundleVersion=undefined frameworkEligible=true frameworkEnabled=true osRelease=10.0.26200 reason=awaiting-framework runtimeRoot=<USERPROFILE>\.cache\codex-runtimes\codex-primary-runtime runtimeSource=archive
2026-09-26T06:16:43.926Z warning [install-primary-runtime] primary_runtime_update_poll_failed errorMessage="Windows primary runtime framework requires a configured MSIX release with a bundle version."
Earlier startup logs also contain:
windows_primary_runtime_framework_activation_skipped architecture=x64 reason=no-persisted-package
Other messages in the same startup:
- Failed to start the Artifact Session host: "Artifact Session host Unix-socket transport is not available on Windows."
- An electron-message-handler fs/readFile request fails with code -32603 and Windows os error 3 ("The system cannot find the path specified"). The requested path is not included in the excerpt.
- bundled_plugins_list_failed and bundled_plugins_marketplace_add_failed: AbortError, "This operation was aborted".
- IpcClient: "Received broadcast but no handler is configured", method=client-status-changed.
These messages are observations, not a confirmed root cause. In particular, the runtime/MSIX configuration may be relevant, but I cannot establish whether it is what blocks startup.
Earlier logs show that the app-server connected, the account lookup succeeded with authenticatedAccountPresent=true and authMethod=chatgpt, the frame loaded, and the React root render was requested.
What steps can reproduce the bug?
- Update the existing Windows desktop installation to Store package 26.924.1866.0 (desktop release 26.924.20706).
- Launch the app.
- Wait more than 10 minutes: the loading spinner remains and the interface does not become available.
- Close and relaunch: the same symptom persists.
This is reproducible on the affected installation; a clean-machine reproduction has not been established. No model/session can be selected while the startup UI is blocked.
What is the expected behavior?
The desktop app should finish startup and display the normal usable interface while preserving existing projects, conversations, and local settings.
Additional information
Troubleshooting already completed
- Fully closing and restarting the app did not resolve it.
- Windows app Repair did not resolve it.
- Checking the Store package with winget reported that the package is already installed and no newer update is available.
- Renamed three Cache / Code Cache / GPUCache directories under the package's LocalCache\Roaming\Codex tree to timestamped backups. The command completed successfully; the spinner remained.
Local project data and the .codex directory have not been deleted. App Reset has not been performed, because a recovery path that preserves local projects and history is needed.
Potentially related: #48373 describes a startup hang on the same desktop release after using Codex with a fresh .codex directory. I have not tested that fresh-.codex sequence, and this report adds the runtime/MSIX messages above; I cannot confirm the two reports have the same cause.
Could maintainers confirm whether awaiting-framework together with desiredBundleVersion=undefined is expected for this Store build, and advise a supported recovery that preserves local data?
Activity
github-actions commentedon Sep 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Asibty commentedon Sep 26, 2026
Additional reproduction from the same desktop release and Windows build:
app_startfailures after about 120.9 seconds withreason=timeout.renderer_readycompleted in about 1.0 s andsettings_readyin about 1.35 s, butshell_visible,home_visible, andsidebar_readywere never recorded.codex-home request hostId=undefined.frameworkEnabled=falseandreason=gate-disabledrather thanreason=awaiting-framework, so the startup hang may be broader than the runtime/MSIX state described in the original report.No raw logs or personal filesystem paths are included.
Asibty commentedon Sep 26, 2026
Additional reproduction details from the same affected Windows machine (2026-09-26):
Recent sanitized log sequence from an affected launch (local time about 16:14):
This indicates that the existing ChatGPT account was recognized, but the post-login online bootstrap timed out and the home route still lacked a host context. Starting offline and then re-authenticating appears to be a temporary workaround, not a reliable fix.
Asibty commentedon Sep 26, 2026
Update after installing the newer production build:
up_to_date.authenticatedAccountPresent=true,authMethod=chatgpt,result=succeeded) and the local app-server 0.158.0-alpha.2.1 initialized successfully.hostId=undefined; the normal shell/home/sidebar never became usable.frameworkEnabled=falseandreason=gate-disabled.So the newer build appears not to fix this startup path. No raw logs, tokens, account identifiers, or personal filesystem paths are included.
clonefarmsro-sys commentedon Sep 26, 2026
I’m seeing the same infinite startup spinner on the ChatGPT Windows app.
Windows 11 Pro 25H2, OS Build 26200.9457
Microsoft Store product ID: 9PLM9XGG6VKS
Package: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0
AppX status: Ok
WebView2 Runtime: 154.0.4258.37
ws.chatgpt.com:443 is reachable
The issue also reproduces on a phone hotspot
Reinstall, Reset-AppxPackage, clearing local data/cache, and reinstalling WebView2 did not fix it.
The app hangs before creating a new session transcript.
I have chatgpt-debug.log and a sanitized ChatGPT-Support.zip available if maintainers want them.
Asibty commentedon Sep 26, 2026
Thank you for confirming the same issue and for offering the diagnostic files. Yes, the sanitized
chatgpt-debug.logandChatGPT-Support.zipwould be helpful for comparing the startup failure. Please make sure that tokens, email addresses, account identifiers, and personal filesystem paths are removed before sharing. If possible, it may be safest to wait for a maintainer to advise how they would like the files provided. I really appreciate your help.Asibty commentedon Sep 26, 2026
Additional reproducible detail: new windows only finish loading when Codex is not visible or focused during initialization.
If I create a new window and keep Codex in the foreground, it remains stuck on the spinner. If I immediately switch to the desktop or another application, wait about 5–10 seconds, and then return to Codex, the new window loads successfully.
During the failing foreground launches, the logs show repeated
getAuthStatus,account/read,config/read, andapp/readcalls. I observed approximately 57–63getAuthStatusrequests per minute, without a renderer crash. An already initialized window remains usable.This appears to be a foreground/focus/visibility lifecycle race during the saved-auth multi-window bootstrap, rather than an invalid credential file.
Version: Codex
26.924.22138, Microsoft Store package26.924.2738.0, Windows 11 Pro 25H2 build26200.9457.vizelio48 commentedon Sep 26, 2026
I have a controlled reproduction that further narrows this startup hang to the saved-auth + window visibility/focus path.
Environment
OpenAI.Codex 26.924.2738.026.924.22138, build116452e782921399a788a842b74ee1944a2e1e6e003a10.158.0-alpha.2.126200.9475, x6432.0.101.673332.0.16.1714Troubleshooting already ruled out
Before these tests I had already tried Windows App Repair, Reset, uninstall/reinstall, and rebooting.
I then created a completely new Windows user account (
ChatGPTTest) and reproduced the same startup spinner there. The new account had fresh per-user package data, fresh%LOCALAPPDATA%\OpenAI\Codex, and a newly-created normal%USERPROFILE%\.codexdirectory (not a symlink/junction). This rules out corruption specific to my main Windows profile.I also forced the app to each GPU separately using Windows per-app graphics preference:
So the basic symptom does not depend on which GPU is selected.
Saved-auth A/B test
The strongest reproduction is around
%USERPROFILE%\.codex\auth.json.auth.jsonout of the way.auth.jsonpresent.auth.jsonagain, relaunch.This is reproducible. The valid saved credential is not rejected: on the failing cold launch the log says:
So this does not look like a corrupt/invalid credential file; the presence of saved auth selects a startup path that can hang.
Failing saved-auth startup
Representative failing launch:
After that, the normal foreground startup never produced:
account/gatewayOAuth/readapp routes mountedshell_visiblehome_visiblesidebar_readyapp_start outcome=successThe app remained on the spinner until terminated.
There is also an
fs/readFileerror with Windowsos error 3, but that same error occurs in successful launches below, so it does not appear sufficient to explain the hang.Visibility/focus reproduction
The most useful finding is that the saved-auth launch succeeds if the main window is hidden immediately, before the spinner state is established.
Repro:
auth.json.If I wait until the spinner is already visible and only then click X, hiding the window does not recover the launch. The window has to be hidden very early.
Successful hidden-window log
The successful run records the visibility transition clearly.
Initially:
After immediately clicking X:
While still hidden/unfocused, the missing auth/bootstrap step appears:
Then the main window becomes visible/focused again and startup completes:
The app then opens ChatGPT pub/sub subscriptions normally.
Interpretation
This looks consistent with a saved-auth startup lifecycle race involving the primary window's visibility/focus state:
gatewayOAuth/readcompletes,hostIdbecomeslocal, shell/home/sidebar become visible, routes mount, and the app automatically re-shows the windowIt also explains why removing
auth.jsonappears to “fix” the launch: that forces the sign-in startup path, which does not hit the same failing saved-auth/visible-window sequence.This behavior is deterministic enough on my machine that it may be useful as a direct reproduction for the visibility/focus lifecycle race discussed above.
Asibty commentedon Sep 26, 2026
@vizelio48 Thank you very much for the detailed testing and for sharing this clear reproduction. It is very helpful and matches what I have been seeing. If you find a more reliable workaround or learn of a proper fix, could you please let me know here? I really appreciate your help.
Asibty commentedon Oct 2, 2026
Update from the affected user (October 2, 2026, Asia/Shanghai): new configuration-related reproduction and correction to my earlier workaround report.
The startup problem still affects me after several recent updates. I found another temporary recovery:
.codex/config.toml, remove only these two lines:This is my observed reproduction, not a confirmed root cause. It may be useful to investigate whether the elevated Windows sandbox setting, its initialization path, or configuration rewriting is involved. I have not established whether removing the setting changes the effective sandbox mode, and I am not recommending disabling sandbox protections as a permanent fix. Please provide a supported recovery that preserves security and local data.
Correction to my earlier visibility workaround: simply switching to the desktop/another app or hiding the window no longer lets me in reliably; the earlier success may have been incidental. The workaround that currently lets me in is launching ChatGPT/Codex, clicking the top-right X to close the window, and then waiting for the window to automatically reappear with the usable interface. This is not the same as fully quitting and relaunching the application.
No new logs or diagnostics are attached, and the current exact installed build has not been verified for this update. Please investigate the remove-setting -> successful entry -> setting reappears -> startup hang sequence. Thank you.