[Windows] Codex App 26.924.2738.0 stuck indefinitely on startup spinner #48558

Activity

1. zoltanonex

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 26, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 26, 2026
3. github-actions commented on Sep 26, 2026

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows desktop app stuck on infinite loading spinner – renderer alive, app://-/index.html route never resolves #48522
   • [Windows][26.924.2738.0] Persistent black window with spinner after update; survives reinstall and cold reboot #48556
   • 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.2738.0] Startup spinner recovers after reloading main index.html, not detached window #48487
   • [Windows][26.924.2738.0] ChatGPT stuck on OpenAI logo/loading screen after update #48557

   Powered by Codex Action
4. Neutrality25 commented on Sep 27, 2026

   

   Neutrality25

   on Sep 27, 2026 – with ChatGPT Codex Connector

   More actions

   Adding an independent reproduction with additional diagnostics from 27 September 2026. The same startup-spinner symptom persists on my Windows laptop after updating to 26.924.2738.0. I am adding evidence here rather than opening a duplicate issue.

   Environment and impact

   • Windows 11 Professional x64, build 26200; Dell Latitude 5510.
   • Microsoft Store/MSIX package OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0; package status reports OK.
   • Desktop-selected bundled engine: 0.158.0-alpha.2.1.
   • Existing CODEX_HOME=%USERPROFILE%\.codex_clean_test, consistent in user and PowerShell process environment.
   • Normal Start-menu activation opens a window with only a spinner; projects and threads never appear.
   • Before this update the desktop could display projects, but follow-up prompts frequently hung. Mobile Remote Control had provided a working alternative for several weeks. Whether those earlier prompt hangs have the same cause is unknown.

   Reproduction and unsuccessful recovery

   1. Accept/install the in-app update.
   2. Launch normally from Start.
   3. Observe the indefinite startup spinner; it persisted for more than 25 minutes during a logged run.

   The following did not resolve it:

   • Windows app Repair and full laptop restart.
   • A launch with 2,536 MB free physical RAM before launch, with no ChatGPT processes running.
   • codex://settings and codex://threads/new.
   • With ChatGPT fully stopped, renaming Cache, Code Cache, and GPUCache under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Default, then relaunching and waiting two minutes. All three renames succeeded; the spinner persisted.

   No reset, reinstall, new profile, or session removal was performed during this investigation.

   Desktop log evidence

   The current spinning launch successfully starts its engine, initializes the connection, and continues receiving replies. Selected fields from the logs below (timestamps UTC; unrelated identifiers/fields omitted):

   2026-09-27T11:11:41.915Z initialize_handshake_result durationMs=264 outcome=success transportKind=stdio
   2026-09-27T11:11:42.400Z Host startup critical-path phases completed startupElapsedMs=2189
   2026-09-27T11:11:45.320Z React root render requested
   2026-09-27T11:11:46.296Z [chatgpt-account-lookup] authenticatedAccountPresent=true authMethod=chatgpt result=succeeded
   2026-09-27T11:20:13.341Z chatgpt_pubsub_conversation_update_received
   2026-09-27T11:36:53.963Z response_routed durationMs=5 errorCode=null method=configRequirements/read
   

   Successful configRequirements/read responses recur at roughly five-minute intervals during the spinner.

   An earlier launch the same morning explicitly records:

   2026-09-27T08:43:35.280Z client.performance.span
   name=app_start outcome=failure reason=timeout durationMs=125439.3
   initialSurface=home
   marksMs={"renderer_entry_evaluated":5419.1,"host_services_ready":5504.6,"renderer_ready":5910.8,"host_startup_ready":5916.2,"settings_ready":6438.8}
   buildCommitSha=2e782921399a788a842b74ee1944a2e1e6e003a1 buildNumber=11645
   

   Both launches also contain the Artifact Session Unix-socket warning described in this issue. Engine initialization succeeds afterward; I am not claiming that warning is causal.

   Additional diagnostic findings

   Running doctor --json using the exact executable selected by the desktop:

   • Configuration parses; stored ChatGPT authentication is configured.
   • Provider HTTP reachability and Responses WebSocket handshake pass (HTTP 101).
   • All inspected existing SQLite databases pass integrity checks.
   • Doctor incorrectly reports the desktop as not running: it returns desktop.app.version.details.running=false and an OK handshake result whose summary is "the desktop application is not running", despite a simultaneous process listing showing the packaged ChatGPT main process, its children, and its child codex.exe. That handshake check therefore does not establish connection health.
   • Doctor's missing rg.exe warning is not reproduced when testing the exact bundled executable from the desktop logs: it runs and reports ripgrep 15.2.0.
   • There is an archived-thread inventory discrepancy (47 files / 46 rows; one reported duplicate thread ID). All 33 active files have matching rows. The two matching archived filenames differ, one contains two UUIDs, and the internal IDs have not been inspected. No connection to the spinner is established.
   • Doctor warns that the optional node_repl MCP environment variable CODEX_WINDOWS_REGISTERED_CORE is absent in the external PowerShell diagnostic environment; its relevance to the desktop launch is unverified.

   The live desktop log files sometimes appeared as Length 0 in directory listings while Get-Content returned their actual populated content. Excluding zero-length files selected an older launch, so matching the filename's process ID and reading directly was necessary.

   A separate attempt to launch ChatGPT.exe directly with Chromium logging flags failed with "The process has no package identity." Returning to normal Start-menu activation restored the original spinner behaviour. That diagnostic-launch error should be distinguished from the normal-activation bug.

   Request

   Please investigate the incomplete interface startup and advise on a supported way to capture renderer diagnostics while preserving Windows package identity. Recovery guidance that preserves conversations, the existing profile, and the repaired Chrome integration would be appreciated. These observations do not establish a root cause; full logs are retained for a suitable private diagnostic channel.
5. Neutrality25 commented on Sep 28, 2026

   

   Neutrality25

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   Update from the independent reproduction above (28 September 2026): While the desktop remained on its startup spinner, I identified the single codex.exe child of the packaged ChatGPT.exe main process whose command line contains app-server, then ended only that child process with Stop-Process -Id <PID> -Force. I left the desktop window open. The Codex interface loaded successfully after the desktop restarted its app-server.

   This is a successful workaround for that launch, not yet evidence of a permanent fix or a confirmed root cause. It may help narrow the startup race/reconnection path. I have not yet established whether it survives a normal app relaunch or whether sending a prompt works. No profile, session files, or app installation were changed.
6. unnathLS commented on Sep 28, 2026

   

   unnathLS

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproducible detail from another Windows installation of Codex App 26.924.2738.0:

   Environment:

   • Windows 11 x64
   • Codex App 26.924.2738.0
   • App installed as MSIX package (OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0)

   Observed behavior:

   • A true cold start consistently opens to the gray/black window with the centered spinner.
   • Launching from PowerToys Run vs. the Windows Start menu makes no difference.
   • Clearing GPUPersistentCache, GrShaderCache, ShaderCache, Default\Cache, Default\Code Cache, and Default\GPUCache did not fix it.
   • Renaming ~/.codex/config.toml temporarily allowed one successful launch, but the issue returned after a full process restart, so config was not the root cause.

   Process-level reproduction:

   1. Kill all ChatGPT.exe processes.
   2. Start Codex.
   3. The spinner hang appears.
   4. The initial renderer processes are created with renderer-client-id=5, 6, and 7.
   5. Killing ONLY the renderer with --renderer-client-id=5 immediately causes the UI to reload and become fully usable.
   6. This was reproduced again from another cold start with a different PID but the same renderer-client-id=5.

   Example process list during a failed cold start:

   • renderer PID 864 -> renderer-client-id=5
   • renderer PID 11092 -> renderer-client-id=6
   • renderer PID 11576 -> renderer-client-id=7

   Workaround:

   Get-CimInstance Win32_Process |
   Where-Object {
       $_.Name -eq "ChatGPT.exe" -and
       $_.CommandLine -match '--type=renderer' -and
       $_.CommandLine -match '--renderer-client-id=5'
   } |
   ForEach-Object {
       Stop-Process -Id $_.ProcessId -Force
   }

   After terminating only client-id=5, the main process respawns the renderer and the Codex UI loads normally.

   This suggests the initial main renderer may enter a bad state during cold startup, while the replacement renderer initializes correctly.