Windows desktop stuck on startup spinner; Remote still works

The Windows desktop app shows its splash logo, then a blank screen and persistent centered spinner. No sidebar or menus. Codex Remote still works from my phone.

Version: OpenAI.Codex 26.924.2738.0. Logs report release 26.924.22138, build 11645.

Tried without success: PC restart, app update, Windows Repair, Ctrl+R, rebuilding Cache/Code Cache/GPUCache, and a fresh browser profile. Original profile restored. Ctrl+Shift+I does not open Developer Tools.

Logs: app_start outcome=failure reason=timeout after approximately 123 seconds, despite renderer_ready, host_startup_ready, and settings_ready. Account/configuration and subsequent plugin-list requests succeed. Root cause unknown.

Please advise how to collect renderer diagnostics without an accessible interface or Developer Tools.

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

Windows desktop app stuck on loading screen after update — app_start bootstrap timeout after codex-home request (26.924.2738.0) #48463
[Windows 26.924] Every cold startup stalls on Loading; restarting only app-server restores UI #48466
[Windows][26.924.1866.0] Desktop stuck on gray loading screen while backend and Pet remain active #48216
[Windows][26.924.2738.0] Repeated startup/loading hang; Event ID 1002 #48457
[Windows][26.924.1866.0] Codex App stuck on blank screen with infinite spinner at startup #48364

Powered by Codex Action

Confirming this on another Windows machine with the same installed package and build. The desktop app remains unusable after Windows reports a successful package repair.

Environment

Windows 11 Home 25H2, build 26200.9457, x64.
Microsoft Store package: OpenAI.Codex, version 26.924.2738.0.
App build reported in logs: 11645; build commit: 2e782921399a788a842b74ee1944a2e1e6e003a1.
Package status is OK. The configured Microsoft Store source reports no newer version available as of September 27, 2026.

Reproduction and attempted recovery

Launch ChatGPT/Codex through its registered Windows app entry.
The window opens but remains blank/loading; the normal chat interface is unavailable.
Back up the saved application state and unsent drafts.
Run winget repair --id 9PLM9XGG6VKS --exact --source msstore (with silent/noninteractive options).
Windows reports Repair operation completed successfully.
Reopen through the registered Windows app entry. The same blank/loading behavior persists; visually confirmed by the user. All three saved drafts remained unchanged.

A successful package repair and running renderer processes have not restored a usable interface. No uninstall/reinstall or destructive Reset was performed in this attempt.

Sanitized post-repair evidence (2026-09-27 UTC)

18:16:21: primary window finishes loading and becomes ready-to-show; host startup critical-path phases complete.
18:16:24: account lookup reports result=succeeded, authenticatedAccountPresent=true, authMethod=chatgpt.
Account/configuration and Windows sandbox readiness requests return with errorCode=null.
18:18:23: startup still times out:

name=app_start
outcome=failure
reason=timeout
initialSurface=home
durationMs=122476.8
marksMs={
  "renderer_entry_evaluated":2471.6,
  "host_services_ready":2495.8,
  "renderer_ready":2666,
  "host_startup_ready":2668.3,
  "settings_ready":3018.1
}

No shell/sidebar/content-visible completion marks appear in that startup event. This narrows the observed failure to UI startup after those initialization milestones; it does not establish the underlying cause.

The local config.toml parses successfully and contains zero NUL bytes, so the specific corruption described in #44374 is not present here.

Separately, a diagnostic attempt to launch ChatGPT.exe directly produced “The process has no package identity.” That was an artifact of the diagnostic launch method, not the normal-launch failure above. The app was subsequently reopened using its registered Windows app entry.

Related report: #48313. Please provide a supported way to collect the relevant renderer/startup trace while the interface is inaccessible, or a confirmed recovery for this build. Raw logs, credentials, conversation contents, and local project paths are intentionally not attached.

I was able to fix it for me temporarily by opening the task manager, looking for ChatGPT and finishing the top inner task. Codex was open at the time, the finished task restarts and the UI loads.

I can reproduce a closely related persistent startup-spinner failure on the same Windows package, with a concrete trigger and sanitized diagnostics.

Environment

Windows 11 Home 10.0.26200 x64 (pt-BR)
OpenAI.Codex 26.924.2738.0
codex-cli 0.158.0-alpha.2.1
Windows sandbox: elevated (install default, not modified)
Fresh install; one local thread

Trigger observed

Codex was working normally.
An active turn raised an async UI question offering an alternative workspace path.
I typed 1 in the composer intending to select the first option instead of clicking the UI option.
Logs show that reply entered thread-queued-followups-changed; there was no turn/start for it.
The async question remained pending and the turn never completed.
A later message was queued too.
Around the same time the renderer logged ~30 ResizeObserver loop completed with undelivered notifications errors in ~6 seconds.
After closing the app, every relaunch (7+ attempts) opens a blank/white window with a centered spinner indefinitely; the conversation list never loads.

Diagnostics

codex doctor --summary: 21 ok / 0 fail; databases healthy; rollout/state DB inventory agrees; auth configured; config loaded.
codex.exe initializes successfully in ~150 ms.
On stuck launches, renderer calls stop after windowsSandbox/readiness (answered in ~10 ms). No subsequent thread/*, collaborationMode/list, plugin/installed, or mcpServerStatus/list calls occur.
Full close of all Codex package processes + relaunch: no change.
Session Storage isolated/recreated empty: no change; original restored.
Local Storage isolated/recreated: no change; recreated LevelDB log remained 0 bytes; original restored.
.codex, IndexedDB, sandbox settings and Windows were not modified.

Expected
A typed reply to a pending async question should either be interpreted when unambiguous, or the UI should tell the user to click an option. It should not be silently queued behind the turn that is waiting for that answer. A pending question/queued-followup state should not make subsequent app launches unusable.

Impact
The Windows desktop app is completely unusable across relaunches even though the app-server, authentication, databases, and thread inventory remain healthy.

I have a sanitized diagnostic package with timeline, version info, incident/relaunch logs, and a screenshot of the blank spinner state. Raw browser storage and credentials are excluded. I can provide the sanitized files if useful.

One hypothesis is that the unresolved async-question/queued-followup state triggers the renderer startup failure, but that is not proven. Session Storage and Local Storage have been ruled out on this machine.

@rabrab92

Reproducible update from another affected Windows installation. The local desktop spinner is permanent; the 121-second value below is only the telemetry timeout and the UI does not recover afterward. Remote control/app-server remain usable while the local window is stuck.

Environment

Windows 11 Pro 23H2 (10.0.22631), x64
Microsoft Store package OpenAI.Codex 26.924.2738.0
App build 11645, commit 2e782921399a788a842b74ee1944a2e1e6e003a1
codex-cli 0.158.0-alpha.2.1
Update check reports the installed release is current

Cold-start behavior

Account lookup succeeds and authentication is present.
App-server initializes; config/account/sandbox requests return successfully.
codex-home request is emitted.
The local UI remains on the centered spinner indefinitely.
Telemetry eventually records:

name=app_start
outcome=failure
reason=timeout
durationMs=121116
marksMs={
  "renderer_entry_evaluated":1110.8,
  "host_services_ready":1134.4,
  "renderer_ready":1268.6,
  "host_startup_ready":1271.9,
  "settings_ready":1618.7
}

There are no shell_visible, home_visible, or sidebar_ready marks on the failed start.

Configuration ruled out

User config now validates with 0 errors against the current official config-schema.json.
codex doctor reports config loaded successfully.
Third-party Git marketplace startup work was removed; the permanent spinner still reproduces.
Renderer caches and Local/Session/WebStorage isolation did not provide a durable fix.

Version/feature mismatch evidence
The desktop/app-server log repeatedly reports:

ignoring invalid experimental feature enablement keys: apps_mcp_path_override
Codex CLI process exited classifiedAsExpected=false code=1

The online official config schema still exposes features.apps_mcp_path_override, while this bundled local CLI lists it as removed. Explicitly setting it to false does not stop the experimental enablement warning, suggesting the value is coming from desktop/cloud feature enablement rather than the user config.

Reliable temporary workaround
With Codex left open and stuck, terminate only the primary renderer child (not the root ChatGPT.exe, not codex.exe). In this run the stuck primary renderer was --renderer-client-id=5. Electron immediately respawned that renderer, and the same root process then recorded:

name=app_start
outcome=success
durationMs=7323
marksMs={
  "shell_visible":5951.3,
  "home_visible":5951.4,
  "sidebar_ready":7322.8
}

This matches the workaround reported above by @rabrab92 and makes it reproducible: restarting only the primary renderer reliably restores the UI, whereas restarting the whole app reproduces the permanent spinner.

Please investigate the first-renderer startup path and the apps_mcp_path_override desktop/cloud vs bundled-CLI mismatch. A screenshot of the permanent centered-spinner state and sanitized logs are available; no credentials, raw conversations, account IDs, or private project paths are included here.

Additional Windows reproduction data from build 11645 / package 26.924.2738.0:

With the recovery threshold reduced to 5 seconds, root PID 40916 was detected at 22:38:14. The initial main renderer PID 36356 (--renderer-client-id=5) was terminated at 22:38:20.
Electron spawned replacement renderer PID 7264, but that first replacement also remained visually stuck. Its app_start span did not report success until 79.472s (shell_visible=79.203s, sidebar_ready=79.472s), and the local UI was still reported unusable.
Terminating only replacement renderer PID 7264 caused Electron to spawn PID 9936. That second replacement completed normally in 8.385s (shell_visible=7.210s, sidebar_ready=8.385s, outcome=success). The root ChatGPT.exe and codex.exe were not terminated.
The same issue also affects Open conversation in new window inside an already-running root process. In one captured case, the new large Electron window paired with renderer PID 8508 / client id 17; terminating only that renderer after 5 seconds produced replacement PID 21512 about 1.3 seconds later.

The local mitigation is now: after a stalled startup, restart only client-id 5 at 5 seconds; if that replacement still has no shell_visible after 12 seconds, restart that replacement once more. For an in-app new conversation window, pair the newly created large Chrome_WidgetWin_1 with the renderer created at the same time and restart only that renderer. This strongly suggests the fault is renderer/bootstrap state rather than authentication, app-server availability, or the root Electron process.

Observed on Windows 11 x64 (build 26200), Codex App 26.924.2738.0, bundled app-server 0.158.0-alpha.2.1:

The window stays on a loading spinner even though local app-server initialization and account lookup succeed.
Disabling the offline remote's auto-connect while the app was fully stopped stopped the offline retry loop, but the spinner remained. The app still selected the saved remote and logged Connection for host ID ... not found.
Restarting only the primary renderer restored the UI; the user confirmed recovery.
Fully restarting the app brought the spinner back, with remote auto-connect still disabled.
Restarting the new desktop instance's renderer children restored the UI again, also confirmed by the user.

The desktop root process and Codex backend were kept running during both renderer recoveries. No app-data reset, cache clearing, or conversation deletion was performed.

Renderer restart provided temporary recovery twice, but did not fix the next full app launch. Root cause remains unconfirmed.

Still reproducible after updating to 26.928.1915.0 (build 12246) on Windows 11 x64 (build 26200). Remote control from phone keeps working the whole time.

Onset: the last launch where the desktop UI worked was on 26.917.9434.0 (2026-09-26). Every launch since 26.924.1866.0 fails; before that, time-to-mount had already been growing (3 s → ~20 s → 57 s → 120 s).

What the desktop log shows on failing launches

client.performance.span name=app_start outcome=failure reason=timeout after ~123 s; marksMs stops at settings_ready (a working 26.917 launch continued with shell_visible, home_visible, sidebar_ready).
A working launch logs [electron-fetch-handler] codex-home request hostId=undefined followed ~0.25 s later by codex-home request hostId=local. Failing launches only ever log the hostId=undefined one. When the UI finally mounts after a workaround, codex-home request hostId=local appears just before [startup][renderer] app routes mounted.

Workaround results

Killing the child codex.exe of ChatGPT.exe while the spinner is showing works, but not always on the first try: it took 2 restarts on one launch, and on another launch 3 restarts plus ~60 s of waiting (mount came ~70 s after hostId=local appeared).
After recovering this way, desktop prompts are unreliable: the thread stays on "Starting your task" / prompts get queued (thread-queued-followups-changed) even though the turn actually runs and completes in the rollout, and the log shows Received turn/started for unknown conversation / Received turn/completed for unknown conversation. The same thread driven from the phone updates normally.

Ruled out locally (no effect): fresh Session Storage / Local Storage, moving .codex-global-state.json aside, moving large rollout files (>300 MB) out of sessions, freeing memory.

Possibly related: after the 26.928 update, the runtime folder %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash> changed, but the cached unified-computer-use plugin (.codex\plugins\cache\openai-bundled\unified-computer-use\26.924.22138\.mcp.json) and notify in config.toml still pointed to the removed folder (MCP startup failed: ... os error 3). The bundled-plugin reconcile that would refresh it seems to run only after the UI mounts. Fixing those paths did not fix the spinner by itself.

Still reproducible on OpenAI.Codex 26.928.2636.0.

Environment:

Windows 11 Pro 23H2, build 22631.6199
ChatGPT Plus
Previous affected app version: 26.924.2738.0

Behavior:

On 26.924.2738.0 the app was stuck on an endless startup spinner.
After updating to 26.928.2636.0, the spinner was replaced by the OpenAI logo on a white splash screen, but the app still never loads chats or projects.
The browser version works correctly on the same computer and account.

Troubleshooting already tried:

Windows App Repair and Reset
Full uninstall/reinstall from Microsoft Store
Windows restart
Microsoft Store cache reset
Alternate network/mobile hotspot
--disable-features=CalculateNativeWinOcclusion workaround
Restarting the internal codex.exe process; this only briefly opened an incomplete UI without projects, and the next normal launch returned to the stuck startup screen

Additional diagnostic detail:

%USERPROFILE%\.codex\sessions does not exist
%USERPROFILE%\.codex\archived_sessions does not exist

So there are no session transcripts available to attach, and the app never reaches the composer, so I cannot generate an in-app feedback/session ID.

Confirmed temporary recovery on OpenAI.Codex 26.928.2636.0, build 12404, Windows 11. The update did not fix the blank/loading screen, but restarting only the stuck primary UI renderer restored my chats and sidebar. I confirmed the UI was usable afterward.

Thanks to the earlier commenters who identified this workaround. My local SOL applied it successfully with one renderer restart.

What worked:

Leave the stuck app open.
Back up the saved Codex state/drafts (.codex-global-state.json in your Codex home) and verify the backup.
Inspect the live ChatGPT.exe process tree and identify the primary UI renderer child. In my instance it had --type=renderer --renderer-client-id=5. Do not assume that client ID or someone else's PID identifies the correct process on your machine.
Terminate only that verified renderer process. Leave the root ChatGPT.exe, codex.exe backend, GPU process, and other windows running. Do not end the entire Task Manager app group.
Let the app automatically respawn the renderer, then verify that chats/sidebar actually appear and a chat opens.

Before recovery, the startup log timed out at 122,753 ms, with initialization marks ending at settings_ready. After recovery, the same root app and backend remained running and the log reported:

name=app_start outcome=success
durationMs=11266.2
shell_visible=10342.8
home_visible=10342.8
sidebar_ready=11266

No reset, reinstall, cache deletion, configuration changes, or security-setting changes were needed.

Tell your local SOL:

My Windows ChatGPT/Codex desktop app is stuck on a blank/loading screen. Apply the targeted renderer-restart workaround from this issue. First back up and verify my saved state and drafts. Inspect the current process tree and identify the stuck primary UI renderer from live evidence; do not blindly assume a PID or renderer-client-id. If its identity is ambiguous, stop before terminating anything. Restart only that renderer, keeping the root ChatGPT.exe, codex.exe backend, other windows, and active work running. Do not reset app data, clear caches, or change security settings. Verify the replacement renderer's startup logs and ask me to confirm that chats are visible and usable. If it fails, inspect the new evidence instead of repeatedly killing processes.

This recovered the current window. It is not a permanent fix, and I have not verified recovery across a subsequent full app restart. The underlying startup defect remains unresolved.

Additional observation / temporary recovery path on OpenAI.Codex 26.928.2636.0:

I was able to get the Windows desktop app working again, at least temporarily, with the following sequence:

In Windows Task Manager I terminated three lower-level Codex-related tasks/processes, including codex.exe, a Host process, and a process shown in Efficiency mode. These appeared duplicated.
The app window then changed: a partial/quasi sidebar became visible, and the center of the window showed a prompt related to updating the Windows environment.
I started that update and waited until it completed.
The partial sidebar was still visible, so I signed out of ChatGPT and then signed back in.
After signing back in, the normal ChatGPT desktop UI loaded, including the sidebar/menu in the state I had previously left it when the app was working correctly.

At the moment the app is usable again, but I do not know whether this recovery will survive the next restart.

This may be relevant because terminating the duplicated Codex/Host processes appeared to let startup progress far enough to expose the Windows environment update prompt, and signing out/in after that restored the full UI.

Additional diagnostic evidence from an affected Windows installation, observed 2026-10-01. The startup failure persists on OpenAI.Codex 26.928.3736.0 (build 12553) while native iPhone Remote remains usable.

Environment

Windows 11 Pro, version/build 10.0.26300, x64.
Current installed Windows package: OpenAI.Codex 26.928.3736.0, package status OK.
Also reproduced on package 26.928.2636.0.
Bundled Codex backend: 0.159.2.
Versions were read from installed package/runtime metadata and logs; the desktop About dialog was not used.
Subscription and iOS version were not collected.

Observed behavior and reproduction

The user reports that the local desktop app remains on its loading screen while working through native Remote from an iPhone. Phone connectivity is working; remote tasks can execute on the same computer.

Use the signed-in Windows desktop installation with native iPhone Remote connected.
Close and relaunch the desktop app. The latest verified test used its registered Windows app entry.
The local UI fails to finish startup. Repeated launches record app_start outcome=failure reason=timeout after approximately 121–122 seconds.
The local backend initializes, account lookup succeeds, and Remote/Local Work connections succeed despite the desktop startup failure.

The original trigger is unknown. A clean-install reproduction has not been established, and remote activity has not been proven to cause the failure.

Latest sanitized startup evidence

Latest launch: 2026-10-01 07:14:47 UTC. Startup failure recorded at 07:16:52.617 UTC:

clientPlatform=win32
hostType=electron
buildNumber=12553
initialSurface=home
name=app_start
outcome=failure
reason=timeout
durationMs=121914.5
marksMs={
  "renderer_entry_evaluated":1908.6,
  "host_services_ready":1940.1,
  "renderer_ready":2106.3,
  "host_startup_ready":2108.3,
  "settings_ready":2531
}

No shell_visible, sidebar_ready, or home_visible completion marks appear in this failed startup event.

During that launch:

Local app-server initialization succeeded in 129 ms.
Account lookup reported result=succeeded, authenticatedAccountPresent=true, hasEverErrored=false.
WebSocket initialization succeeded in 117 ms.
Local Work executor connected to rendezvous.

Other observed errors, with identifiers removed:

Conversation state not found
Received turn/started for unknown conversation
Received turn/completed for unknown conversation
fs/readFile: code=-32602, message="fs/readFile requires an environmentId"

The first and fourth errors also appeared in the latest launch; unknown-conversation turn events were observed in earlier affected launches. These are correlation evidence, not a confirmed root cause. Earlier startup logs also contained an app-tools MCP tools/list timeout and optional runtime path errors; their relationship to the loading screen is unproven.

Windows Application Hang event 1002 separately recorded ChatGPT.exe becoming unresponsive on the same date.

Recovery attempts and outcomes

Repeated full app restarts: startup timeout persisted.
Updating from package 26.928.2636.0 to 26.928.3736.0: startup timeout persisted.
Backed up and regenerated eight browser/code/GPU/shader cache folders in the physical MSIX profile: the following launch still timed out after 121.6 seconds.
Changed only the saved home composer mode from work to chat, after backing up the UI preference file and verifying the change was limited to that preference; relaunched through the registered Windows app entry: latest startup still failed after 121.9 seconds, as shown above.

Credentials, Remote pairing, projects, and chat databases were not edited by those recovery attempts. No destructive app-data Reset was performed. A targeted renderer-only or backend-only restart has not been tested on this installation.

The latest retry is confirmed by telemetry; a fresh visual confirmation after that retry was not collected.

Expected behavior / request

The local desktop should reach a usable home/sidebar while its backend and native Remote are connected. Please investigate the startup completion path after settings_ready and provide a supported trace collection method or recovery/fixed build that preserves user data.

This update contains sanitized excerpts only. Usernames, machine names, personal paths, IP addresses, account identifiers, conversation IDs, credentials, full configuration, UI-state backups, and session transcripts are omitted.

Navigation Menu

Repository navigation

Windows desktop stuck on startup spinner; Remote still works #48484

Environment

Observed behavior and reproduction

Latest sanitized startup evidence

Recovery attempts and outcomes

Expected behavior / request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows desktop stuck on startup spinner; Remote still works #48484

Description

Activity

github-actions commented on Sep 26, 2026

Sahil170595 commented on Sep 27, 2026

rabrab92 commented on Sep 27, 2026

hudsonfm1 commented on Sep 28, 2026

ruotun commented on Sep 28, 2026

ruotun commented on Sep 28, 2026

Yung-Chih-Lo commented on Sep 29, 2026

yasuhiroohnaka-ux commented on Sep 30, 2026

esce-x commented on Sep 30, 2026

Sahil170595 commented on Sep 30, 2026

esce-x commented on Sep 30, 2026

haideralmesaody commented on Oct 1, 2026

Environment

Observed behavior and reproduction

Latest sanitized startup evidence

Recovery attempts and outcomes

Expected behavior / request

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions