[Windows][Desktop][Auth] App hangs on infinite spinner when auth.json exists before process startup

Summary

The Codex/ChatGPT Windows desktop app enters an indefinite loading state when a valid $CODEX_HOME\auth.json is already present when the packaged app process starts. The window opens and displays a spinner, but the main application routes never mount.

If auth.json is temporarily moved out of $CODEX_HOME before launching the same app build with the same project database and configuration, the renderer mounts normally. The desktop app later recreates auth.json from the existing account/session, signs in successfully, and loads the project.

This is consistently reproducible with both zero projects and one project in the local project database. The project database does not appear to be the trigger.

User report and troubleshooting-session context

I am troubleshooting the Codex desktop app on Windows 11 64-bit. For approximately the last month, the app has shown progressively worse performance when sending prompts, including long delays, indefinite buffering, and prompts that appear never to complete. The current failure escalated into an infinite loading spinner during application startup, making the desktop app effectively unusable.

The app was too slow and unresponsive to troubleshoot from within its own interface, so I had to continue the investigation through Codex CLI. This report summarizes that troubleshooting session, the controlled tests performed, the logs collected, and the only reliable workaround found.

Troubleshooting-session chronology

The desktop app reported a database-related problem and offered a retry action.
Selecting retry led to a permanent loading spinner.
Restarting the app did not clear the spinner.
The Microsoft Store app was uninstalled and reinstalled, but the startup failure continued.
Local chat/application state was reset while preserving the actual project source directories.
Nonessential plugins were removed or disabled to rule out plugin startup failures.
Fresh CODEX_HOME profiles were tested with zero and one local project records.
The issue reproduced whenever a valid auth.json existed before process startup.
Moving only auth.json out of the way before launch allowed the renderer to mount, after which the app recreated authentication and signed in successfully.
The original project directory remained untouched and could be added back to the app.

Impact / severity

High — startup-blocking. The app becomes unusable and local projects/chats cannot be accessed through the normal launcher. Reinstalling and resetting local app data did not resolve it.

Environment

OS: Microsoft Windows 11 Pro, 64-bit
OS version: 10.0.26200 (build 26200.9457, 25H2)
Microsoft Store package: OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0
Package version: 26.924.1866.0
Runtime/app version shown in logs: 26.924.20706
Desktop build number: 11431
Build commit: 97cf4a3c7cee97ad6cbb13cb9ab228321db3a385
Bundled app-server version: 0.158.0-alpha.2
Separately installed Codex CLI: codex-cli 0.154.0
Authentication method: ChatGPT account login
Reproduced using clean alternate CODEX_HOME profiles
Third-party MCP/plugin configuration was removed or disabled during isolation

Steps to reproduce

Set CODEX_HOME to a clean test profile.
Authenticate so that $CODEX_HOME\auth.json exists.
Fully terminate all Codex/ChatGPT desktop processes.
Launch the packaged app using: shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App
Observe that the desktop window opens but remains on the loading spinner indefinitely.
Fully terminate the app again.
Move only $CODEX_HOME\auth.json to a timestamped backup. Do not modify the project database or project files.
Launch the exact same packaged app again.
Observe that renderer routes mount in approximately 3.5 seconds.
Wait for the app to restore/recreate authentication. It signs in and completes startup successfully, with the existing project still present.

Expected result

The app should read the existing valid authentication state, mount its routes, and show the authenticated home/project UI. An auth refresh failure should produce a recoverable sign-in screen or actionable error rather than block route mounting.

Actual result

When auth.json exists at process startup, the app window remains on an infinite spinner. In failing runs, logging reaches an authenticated bootstrap/pubsub state but never records app routes mounted or a successful app_start span.

Reproduction matrix

Test	auth.json at process start	Local project count	Result
Clean profile, authenticated	Present	0	Infinite spinner
Clean profile, authenticated	Present	1	Infinite spinner
Same profile/database	Temporarily absent	1	Routes mount; auth is recreated; startup succeeds

This matrix rules out the project row as the primary trigger. The differentiating condition is whether auth.json exists before process startup.

Relevant logs

Failure, zero projects:

2026-09-26T06:20:38.102Z Local app-server project migration completed projectCount=0
2026-09-26T06:20:40.308Z response_routed method=account/read
2026-09-26T06:20:41.373Z codex-home request hostId=undefined
2026-09-26T06:20:44.260Z chatgpt_pubsub_topic_subscribed topicId=resource-updates

Failure, one project:

2026-09-26T06:19:15.934Z Local app-server project migration completed projectCount=1
2026-09-26T06:19:17.892Z response_routed method=account/read
2026-09-26T06:19:18.929Z codex-home request hostId=undefined
2026-09-26T06:19:21.723Z chatgpt_pubsub_topic_subscribed topicId=resource-updates

Successful control, auth absent only during launch:

2026-09-26T06:28:11.191Z Local app-server project migration completed projectCount=1
2026-09-26T06:28:14.494Z [startup][renderer] app routes mounted after 3546ms
2026-09-26T06:29:11.085Z [startup][renderer] app routes mounted after 60212ms
2026-09-26T06:29:11.509Z response_routed method=model/list
2026-09-26T06:29:11.882Z chatgpt_pubsub_topic_subscribed topicId=resource-updates
2026-09-26T06:29:11.982Z name=app_start outcome=success buildNumber=11431
2026-09-26T06:29:12.721Z codex-home request hostId=local

Troubleshooting already performed

Fully terminated and restarted the app repeatedly.
Used the retry flow; it returned to an indefinite spinner.
Uninstalled and reinstalled the Microsoft Store package.
Reset the AppX package/local application data.
Tested multiple fresh CODEX_HOME profiles.
Tested with zero projects and one project.
Reauthenticated using Codex CLI.
Removed/disabled nonessential plugin and MCP configuration.
Preserved the project directory without modifying source files.
Confirmed Codex CLI reports a valid ChatGPT login.
Confirmed that moving only auth.json before startup changes the outcome from failure to success.

Working workaround

Move auth.json to a timestamped backup immediately before launching the packaged app:

$codexHome = Join-Path $env:USERPROFILE '.codex-recovery-v4'
$authPath = Join-Path $codexHome 'auth.json'

if (Test-Path -LiteralPath $authPath) {
    $timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
    Move-Item -LiteralPath $authPath -Destination (Join-Path $codexHome "auth.preboot-$timestamp.json")
}

$env:CODEX_HOME = $codexHome
Start-Process 'explorer.exe' 'shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App'

The app later recreates auth.json and signs in from the existing desktop account/session. Project data remains intact because the workaround does not remove the project database or project directory.

Suspected failure area

This is an inference from the A/B startup tests and logs, not a confirmed code-level diagnosis. The renderer appears to wait indefinitely during authenticated bootstrap after account/read, an unresolved codex-home request hostId=undefined, and the resource-update pubsub subscription.

Potential areas to inspect:

Authenticated renderer bootstrap ordering/race conditions.
A promise or state transition waiting on codex-home host resolution.
Pubsub initialization occurring before route mounting without a timeout/error boundary.
Rehydration of an existing ChatGPT desktop account into the Codex app-server session.
A missing fallback from authenticated bootstrap to a recoverable sign-in state.

Requested engineering improvements

Prevent auth refresh/bootstrap from indefinitely blocking the renderer's main routes.
Add a timeout and visible recovery action around authenticated startup dependencies.
Add structured logging after codex-home hostId=undefined.
Add a Windows regression test covering the reproduction matrix.
Preserve local projects and sessions when authentication recovery is required.

Security and privacy

Do not request auth.json; it contains authentication credentials/tokens. Account email addresses, account IDs, access tokens, refresh tokens, private project source, and proprietary chat/session contents have been omitted.

Report date: 2026-09-25 America/Los_Angeles; log timestamps are UTC on 2026-09-26.

Codex-Windows-Auth-Startup-Infinite-Spinner-Bug-Report.md

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

Windows 26.924.20706: Codex works once with fresh .codex, then ChatGPT Desktop hangs on next launch #48373
[Windows][26.924.1866.0] Codex App stuck on blank screen with infinite spinner at startup #48364
[Windows][26.924.20706] Endless startup spinner after update; runtime logs awaiting-framework with undefined bundle version #48377

Powered by Codex Action

Same on build 26.924.2738.0, confirmed by renaming only auth.json — details in #48404.

Same on build 26.924.2738.0, confirmed by renaming only auth.json — details in #48404.

hire me openai! (lol like codex didnt fix it and write ts for me)

Independent reproduction with a very similar Windows Desktop startup signature.

Environment

Codex Desktop Microsoft Store package: OpenAI.Codex 26.924.2738.0
Codex app-server / CLI observed in Desktop logs: 0.158.0-alpha.2.1
Windows-reported values: Windows 10 Home, 25H2, build 26200.9457, x64
Authentication: ChatGPT account
Native Windows agent environment (not WSL)

Symptom

Codex Desktop opens but remains indefinitely on the startup spinner. The process tree remains alive and responsive: Electron main process, renderer(s), GPU process, NetworkService, StorageService, and child codex.exe app-server all remain running.

Backend startup succeeds

Blocked-launch logs show:

[AppServerConnection] Starting app-server connection hostId=local transport=stdio
[AppServerConnection] Transport start success
[AppServerConnection] initialize_handshake_result ... outcome=success
[AppServerConnection] Codex CLI initialized
[AppServerConnection] ... next=connected ... initialized=true

ChatGPT account lookup also succeeds with authenticatedAccountPresent=true.

Renderer/UI divergence

A known successful launch reaches:

React root render requested
app routes mounted
Handled 'ready' message
app_start outcome=success
shell_visible
home_visible

Blocked launches reach the authenticated/bootstrap stage but never reach the route-mount / ready markers. Representative sequence:

React root render requested
remoteControl/status/read        errorCode=null
config/read                      errorCode=null
fs/readFile                      errorCode=-32603 (Windows os error 3)
config/read                      errorCode=null
account/read                     errorCode=null
getAuthStatus                    errorCode=null
[chatgpt-account-lookup]         authenticatedAccountPresent=true result=succeeded
[remote-connections/bootstrap]   shared_object_synced
[desktop-notifications]          service starting
codex-home request               hostId=undefined
experimentalFeature/list         errorCode=null
configRequirements/read          errorCode=null
windowsSandbox/readiness         errorCode=null
chatgpt_pubsub_transport_opened
chatgpt_pubsub_topic_subscribed  topicId=resource-updates

The fs/readFile os error 3 is also present in a successful launch, so it does not appear sufficient by itself to explain the spinner.

Troubleshooting already completed

Store uninstall/reinstall and package reset
Truly fresh .codex state
Reproduced with no old sessions restored
state_5.sqlite neutralization/regeneration
config.toml regeneration
global state neutralization
plugin disable/regeneration
complete Chromium/Electron profile reset
Chrome Codex extension removal
network / DNS / HTTPS / WebSocket / assets CDN checks
sandbox repair/provisioning
SQLite integrity checks via codex doctor
NVIDIA driver update / overlay disabled

None resolved the startup spinner.

Windows sandbox A/B

Current config was:

[windows]
sandbox = "elevated"

The sandbox setup log reports successful provisioning:

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

Per support guidance, I tested:

[windows]
sandbox = "unelevated"

After a full Desktop restart and several minutes of waiting, behavior was unchanged: infinite spinner. The dated sandbox log was not updated by that unelevated launch.

Relationship to this issue

I have not yet performed the specific auth.json present/absent A/B test described in #48383, so I am not claiming the same root cause. However, the blocked-launch signature is notably similar: authenticated bootstrap succeeds, codex-home request hostId=undefined appears, pub/sub initializes, but app routes mounted never appears.

Codex CLI itself is usable on the same machine, which provides a workaround while Desktop is blocked.

I can provide sanitized full Desktop logs from both a successful launch and blocked launches if maintainers want them.

Additional differential evidence from the same affected machine.

Working VS Code path vs failing Desktop path

I verified the parent processes, bundled Codex versions, and command lines for both environments.

VS Code path — works

Parent: Code.exe
VS Code extension: openai.chatgpt 26.5917.62051
Bundled binary:
C:\Users\Utilisateur\.vscode\extensions\openai.chatgpt-26.5917.62051-win32-x64\bin\windows-x86_64\codex.exe
Version:
codex-cli 0.155.0-alpha.16.3

Command line:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

Result: Codex responds normally, reads the active workspace, and can inspect project files.

ChatGPT/Codex Desktop path — fails

Parent: ChatGPT.exe
MSIX package:
OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0
Desktop Codex binary:
C:\Users\Utilisateur\AppData\Local\OpenAI\Codex\bin\faa963e871dd422c\codex.exe
Version:
codex-cli 0.158.0-alpha.2.1

Command line:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled -c plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true

Result: Desktop remains indefinitely on the startup spinner.

Environment comparison

Both tests are on the same Windows machine, same Windows user, same network, same ChatGPT account, and Windows-native execution (not WSL).

So the current observed matrix is:

Windows native environment        OK
Network/auth                      OK
Codex CLI                         OK
VS Code + Codex 0.155             OK
ChatGPT Desktop + Codex 0.158     FAIL (infinite spinner)
Windows sandbox elevated          FAIL
Windows sandbox unelevated        FAIL

This does not prove that 0.158.0-alpha.2.1 or the codex_app plugin flag is the root cause, but it provides a concrete reproducible boundary: the Codex engine path embedded in VS Code works on the same machine while the Desktop chain does not.

If useful, I can also provide the exact parent/child process listings and sanitized blocked-launch Desktop logs showing the failure before app routes mounted.

Additional state-sharing evidence from the same machine.

Desktop modifies the shared `.codex` state; VS Code works again after restoring the pre-Desktop snapshot

Before retesting Desktop, I created a full backup of the working Codex state:

C:\Users\Utilisateur\.codex_BEFORE_DESKTOP_RETEST_20260927

At that point, Codex in VS Code was working normally.

I then:

fully closed VS Code / ChatGPT / Codex processes;
launched ChatGPT/Codex Desktop;
confirmed the Desktop still remained indefinitely on the startup spinner;
closed Desktop;
compared the resulting C:\Users\Utilisateur\.codex tree with the pre-Desktop snapshot.

The Desktop launch changed or created several shared state files, including:

.codex-global-state.json
.codex-global-state.json.bak
config.toml
state_5.sqlite
state_5.sqlite-wal
logs_2.sqlite
queue_1.sqlite-wal
thread_history_1.sqlite
thread_history_1.sqlite-shm
thread_history_1.sqlite-wal
rollout-migrations

Notably, auth.json did not change in that test.

I then archived the post-Desktop state as:

C:\Users\Utilisateur\.codex_AFTER_DESKTOP_RETEST_20260927

and restored the exact pre-Desktop snapshot back to:

C:\Users\Utilisateur\.codex

After relaunching VS Code, Codex immediately succeeded again and confirmed it could read the active workspace:

E:\SOVEREIGN_METHOD

with no file modifications.

Interpretation

This does not prove that the Desktop writes are the root cause of the spinner. However, it confirms that:

Desktop and VS Code share %USERPROFILE%\.codex state;
launching the failing Desktop modifies that shared state;
restoring the pre-Desktop snapshot returns VS Code Codex to the known working state.

Combined with the earlier evidence that VS Code uses bundled Codex 0.155.0-alpha.16.3 while Desktop uses 0.158.0-alpha.2.1 plus the codex_app plugin flag, this suggests the Desktop failure path is interacting with shared state even though the VS Code path remains healthy when that state is restored.

If maintainers want, I can provide a sanitized file-by-file before/after diff (names, sizes, timestamps only) for the shared .codex tree.

I'm having the same problem. September has been awful for Windows users. I've been blocked from using Codex for over 3 weeks from three different bugs (this one included)

+++ same

Confirming this is fixed for me on two Windows 11 machines (Microsoft Store builds):

Machine 1: hung on 26.924.2738.0 and 26.928.2636.0. Fixed on 26.930.2377.0. Two cold launches from the Start menu with auth.json present loaded normally.
Machine 2: hung on 26.928.2636.0 and 26.928.3736.0. Fixed on 26.930.3748.0. It cold-launched normally, and replies in an existing project chat work.

Before the fix, the only workaround was to end the desktop app's codex.exe app-server process about 15 seconds after launch. I no longer need it on either machine.

Navigation Menu

Repository navigation

[Windows][Desktop][Auth] App hangs on infinite spinner when auth.json exists before process startup #48383

Summary

User report and troubleshooting-session context

Troubleshooting-session chronology

Impact / severity

Environment

Steps to reproduce

Expected result

Actual result

Reproduction matrix

Relevant logs

Troubleshooting already performed

Working workaround

Suspected failure area

Requested engineering improvements

Security and privacy

Environment

Symptom

Backend startup succeeds

Renderer/UI divergence

Troubleshooting already completed

Windows sandbox A/B

Relationship to this issue

Working VS Code path vs failing Desktop path

Environment comparison

Desktop modifies the shared `.codex` state; VS Code works again after restoring the pre-Desktop snapshot

Interpretation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows][Desktop][Auth] App hangs on infinite spinner when auth.json exists before process startup #48383

Description

Summary

User report and troubleshooting-session context

Troubleshooting-session chronology

Impact / severity

Environment

Steps to reproduce

Expected result

Actual result

Reproduction matrix

Relevant logs

Troubleshooting already performed

Working workaround

Suspected failure area

Requested engineering improvements

Security and privacy

Activity

github-actions commented on Sep 26, 2026

Coopers22 commented on Sep 26, 2026

mooniethegreat commented on Sep 26, 2026

patrickgiorico commented on Sep 27, 2026

Environment

Symptom

Backend startup succeeds

Renderer/UI divergence

Troubleshooting already completed

Windows sandbox A/B

Relationship to this issue

patrickgiorico commented on Sep 27, 2026

Working VS Code path vs failing Desktop path

Environment comparison

patrickgiorico commented on Sep 27, 2026

Desktop modifies the shared .codex state; VS Code works again after restoring the pre-Desktop snapshot

Interpretation

DesignMike commented on Sep 28, 2026

vanya999666111 commented on Sep 29, 2026

Coopers22 commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Desktop modifies the shared `.codex` state; VS Code works again after restoring the pre-Desktop snapshot