Codex Windows desktop app stuck on logo/loading screen

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

• #19879
• #19808
• #19659
• #19770
• #19415

Powered by Codex Action

I have the same issue as well.

<img width="3071" height="1794" alt="Image" src="https://github.com/user-attachments/assets/daa055c5-09eb-4dc8-986e-e53495c4f74d" />

I’m seeing the same behavior on Windows 11 x64 with Codex OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0.

My issue is #20217. I tried clean reinstall, resetting %USERPROFILE%\.codex, Reset-AppxPackage, updating NVIDIA driver, repairing WebView2, repairing VC++ x64, and launching as Administrator, but it still stays on the logo/loading screen.

I ran into a frustrating issue with the Codex extension in Visual Studio Code — it was stuck on the loading screen and never opened.

After trying multiple fixes (GPU settings, cache cleaning, reinstalling the extension), the root cause turned out to be surprisingly simple:

INSTALL >>> Microsoft Visual C++ Redistributable (x64)
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-supported-redistributable-version

Once I installed it, the extension started working instantly.

If you're facing a similar issue where an extension stays stuck on loading, especially with WebView-based tools, make sure you have the required system dependencies installed.

Sometimes the problem isn’t in the code or the editor — it’s in the system environment.

Hope this helps someone save a few hours.

Same issue, reproducible with clear diagnostic detail that may help narrow it down:

Environment: Windows 11 Enterprise (build 26200), Codex OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0 (also reproduced on the prior auto-updated build 26.623.13972.0 before it self-updated — same symptom on both).

Symptom: App launches (visible in Task Manager as ChatGPT.exe, 5-6 processes: main + gpu-process + utility x2-3 + crashpad-handler), all responding, idle CPU, but never creates a window. No error, no crash, no exception anywhere (Application event log, Codex's own log file, crashpad — all clean).

Log always stops at the identical two lines, every single time:

info Launching app agentRunId=null allowDebugMenu=false allowDevtools=false allowInspectElement=false buildFlavor=prod enableSparkle=false enableUpdater=true nodeEnv=undefined packaged=true platform=win32
info Appshot hotkey inactive configured=true enabled=true platform=win32

Nothing after that — the log file just ends, no matter how long you wait (tested 10+ minutes).

Things I've ruled out, all with no effect on the hang:

• Clearing the desktop app's LocalCache profile (AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache) — full wipe, identical hang on next launch
• Resetting %USERPROFILE%\.codex entirely (fresh folder, no prior config/auth/sessions) — identical hang
• System resource contention — ruled out; other apps (including other MSIX/UWP apps) launch normally and instantly on the same machine at the same time
• VC++ Redistributable — already installed at latest (2022 x64, 14.50.35719)
• Not a duplicate-instance/singleton lock issue — confirmed only one process tree exists

Given it hangs at the exact same point regardless of cache/config state, this looks like a genuine deadlock in the startup sequence itself (likely in whatever runs right after the Appshot hotkey registration — possibly an update check or auth/license handshake with no timeout), not an environment/corruption issue on affected users' machines.

Additional environment details from another reproducible occurrence:

• OS: Windows 11 25H2, build 26200.8894
• Symptom: Codex for Windows launches but remains indefinitely on the OpenAI logo/loading screen and never reaches the main interface.
• Timing: The problem began immediately after the latest Windows update.
• Comparison: Codex web continues to work normally in the browser using the same account.

The issue reproduces on every desktop launch.

Status update — still unresolved:

The Codex Windows desktop app still does not start successfully and never reaches a usable interface on Windows 11 25H2, build 26200.8894. The problem remains reproducible on every launch attempt.

Codex web continues to work normally in the browser using the same account.

Hi,
I wanted to share my troubleshooting and solution because I found that there were actually two separate issues happening at different stages.
Environment:
Windows 11 25H2
Razer Blade 14 (2025)
OpenAI Codex Microsoft Store app
Version: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
Issue 1: App stuck indefinitely on the splash/logo screen
For about two days, Codex would launch but remain stuck on the grey OpenAI logo animation. The login window never appeared.
I tried:
uninstalling/reinstalling the Microsoft Store app multiple times
Windows app repair/reset
restarting Windows
checking Event Viewer
checking permissions
clearing app data
The thing that finally allowed the app to progress past the splash screen was changing the Windows graphics preference:
Settings → System → Display → Graphics → OpenAI Codex → Options → High performance (NVIDIA GPU)
After switching it to the NVIDIA GPU, the app was able to open the login/setup flow.
Issue 2: “Finish Windows setup” loop after signing in
After getting past the splash screen, I became stuck on:
“Finish Windows setup”

Clicking:
“Finish setup”
“Try Windows setup again”
“Continue with limited access”
did not complete setup. No Windows UAC prompt appeared.
I investigated the Codex logs and found the actual cause.
The logs showed Codex was failing to load:
C:\Users\<username>\.codex\config.toml
because the file was corrupted:
Failed to load desktop settings from config.toml

Invalid TOML document

key with no value, expected '='
The app itself was launching correctly, but the corrupted configuration file prevented initialization from completing.
Fix
I renamed the corrupted configuration file:
Open PowerShell and run:
Rename-Item "$env:USERPROFILE\.codex\config.toml" "config.toml.bad"
Then I reopened Codex.
The app regenerated the configuration file and completed setup successfully.
Additional investigation
I also checked the codex:// protocol registration because I found another forum post describing a missing protocol handler. My system did have an incomplete registration, so I repaired:
HKCU\Software\Classes\codex\shell\open\command
However, that was not the final fix in my case. The app still looped until I resolved the corrupted .codex\config.toml.
Final resolution
The complete solution required:
Splash screen forever
→ Set Codex to use the NVIDIA GPU in Windows Graphics Settings.

“Finish Windows setup” loop
→ Rename the corrupted .codex\config.toml file and allow Codex to recreate it.

I hope this helps others troubleshooting this issue. The biggest breakthrough was checking the internal Codex logs rather than continuing with reinstall attempts.

Thanks, @jhoflick. The issue is now resolved on Windows 11 25H2, build 26200.8894. I deleted the OpenAI Codex directory, then restarted the app. Codex recreated the directory and launched normally. No further troubleshooting is needed.

I’m experiencing the same issue on Windows.

Codex package version:
OpenAI.Codex 26.814.5167.0

Symptoms:

• The Windows desktop app remains indefinitely on the splash/loading animation.
• ChatGPT/Codex works normally in the browser.
• The desktop processes remain running, but the main UI never appears.

Network checks:

• Clash Verge TUN mode successfully routes chatgpt.com, ws.chatgpt.com, and ab.chatgpt.com through the proxy.
• No connection timeout or reset errors appear in Clash logs.

Troubleshooting already attempted:

• Restarted Windows
• Switched multiple proxy nodes
• Enabled TUN mode and DNS override
• Repaired Microsoft Edge WebView2
• Reset and reinstalled the Windows app
• Cleared LocalCache, LocalState, and Settings
• Removed ~/.codex/auth.json and tested with a fresh login state

None of these steps resolved the issue.

Windows version:
[Please insert your Windows version here]

A screen recording of the issue is attached.

Same issue on the current unified ChatGPT/Codex Windows desktop app, with additional diagnostics that may help narrow it down.

Environment

• Windows x64
• ChatGPT Plus
• Package: OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0
• Executable: ChatGPT.exe (new unified ChatGPT desktop app)

Symptom
The app repeatedly cycles:

OpenAI logo -> blank/white window -> OpenAI logo -> blank/white window

and never reaches the usable UI.

chatgpt.com works normally in the browser with the same account.

Troubleshooting already tried

• Windows app Reset
• Full-process termination/relaunch
• Global/TUN proxy mode (browser already works normally)
• Rebuilt the Chromium profile by renaming %APPDATA%\Codex\web\Codex
• No corresponding Windows Application Error / crash event

Relevant process state
The app successfully starts the main process, crashpad, GPU process, network service, storage service, multiple renderer processes, and codex.exe. The process remains alive rather than crashing.

Most interesting log line

Electron renderer console [warning] app://-/assets/app-initial-C39uD83t.js:3182
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.

At the same time, the embedded ChatGPT web contents are actually able to navigate and load:

• https://chatgpt.com/ reaches ready-to-commit, finish, and dom
• requests are made successfully to /api/auth/session, /api/auth/link-session, /backend-api/..., and ChatGPT CDN assets
• Chromium debug log contains no net:: or ERR_ network errors
• no crash, fatal, Uncaught, TypeError, ReferenceError, or generic Exception entries were found

This makes the failure look more like a desktop shell/router/render-state problem than an account, network, or process-crash issue: the ChatGPT content loads in the background, but the outer desktop UI remains stuck on the splash/blank loop.

There are also repeated MISSING_TRANSLATION messages for currencyCodes.usdCode/usdSign under zh-CN, but those explicitly fall back to USD / $, so they do not appear to be the root cause.

I can provide a full sanitized Chromium debug log if maintainers need it.