Windows app hangs on splash screen and becomes Not Responding on Windows build 26200 #48148

Activity

1. LoveCaptain

   added

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

   on Sep 25, 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 25, 2026
3. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Linux desktop app hangs forever on splash screen; persists across clean reinstall #46829

   Powered by Codex Action
4. Shogen95 commented on Sep 26, 2026

   

   Shogen95

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Windows 11 x64 build 10.0.26200.

   Codex App package initially reproduced on:

   • OpenAI.Codex 26.924.1866.0

   It then auto-updated during troubleshooting to:

   • OpenAI.Codex 26.924.2738.0
   • Get-AppxPackage status: Ok

   The startup hang persists: the window remains on the loading/splash state and does not reach the usable UI.

   Relevant behavior from the 26.924.1866.0 startup log:

   • codex.exe spawned successfully
   • main frame finished load
   • initialize_handshake_result outcome=success
   • Codex CLI initialized
   • app_server_connection state reaches connected
   • ChatGPT account lookup succeeds with authenticatedAccountPresent=true and result=succeeded
   • React root render requested
   • UI remains stuck afterwards

   This strongly matches the original report: package registration, local app-server, CLI initialization, and authentication all succeed, while the desktop UI fails to complete startup.

   A later package check after the auto-update shows:
   OpenAI.Codex 26.924.2738.0 Status=Ok

   The web version continues to work normally.
5. Shogen95 commented on Sep 26, 2026

   

   Shogen95

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up from the Windows 11 x64 build 10.0.26200 reproduction on Store package OpenAI.Codex 26.924.2738.0:

   The CDP recovery workaround was attempted and did NOT restore the usable desktop UI on this machine.

   The attempted path preserved MSIX package identity, launched with localhost-only remote debugging, waited for the app://-/index.html renderer, allowed startup to settle, and sent Page.reload with ignoreCache=true. The UI remained stuck afterwards.

   This adds a negative result for the workaround on 26.924.2738.0: it can recover some affected machines (as reported elsewhere), but is not reliable across all Windows 26200 reproductions.

   No app reset, reinstall, or deletion of local Codex data was performed during this attempt.
6. dariusbuinovskij commented on Sep 26, 2026

   

   dariusbuinovskij

   on Sep 26, 2026

   More actions

   I reproduced a similar startup freeze on Windows build 26200 with app version 26.924.2738.0.
   Using Codex CLI and a local debugging connection, we identified a specific blocker:

   • The backend successfully initialized and reported version 0.158.0-alpha.2.1.
   • Authentication and app-access checks passed.
   • The renderer’s backend-version state remained null.
   • Gateway OAuth readiness therefore remained "loading", keeping the startup spinner visible indefinitely.
     Passing the actual reported backend version through the renderer’s existing initialization handler immediately changed readiness to "ready" and opened the main interface. This worked repeatedly. No application files, credentials, or persistent settings were manually edited.
     The workaround is memory-only: restarting removed it and reproduced the freeze. This confirms the immediate blocking condition on my machine, but we haven’t determined why the initialization state was missing.
     This may help investigate this issue. I’m including the Codex CLI instructions below; internal identifiers are build-specific and must be verified before applying the workaround.

   Diagnose and temporarily unblock my ChatGPT Windows app, which stays on its startup spinner.

   You may read local app logs and installed app code, launch/restart ChatGPT for diagnostics, and apply the memory-only workaround described below if you verify the same condition. Ask before editing files, changing persistent settings, reinstalling anything, or touching other applications.

   Previously confirmed case:
   - Windows package: OpenAI.Codex_2p2nqsd0c76g0
   - App build: 26.924.2738.0
   - Backend version: 0.158.0-alpha.2.1
   - Backend initialization and authentication succeeded.
   - The renderer’s backend-version state was null.
   - Gateway OAuth readiness remained "loading", blocking startup.
   - Supplying the actual backend version through the existing initialization handler changed readiness to "ready" and immediately opened the main interface.
   - This worked twice but disappeared after restarting.
   
   Procedure:
   
   1. Discover the currently installed package and version using Get-AppxPackage. Do not assume the versions above still apply.
   
   2. Inspect recent startup logs, typically under:
      %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\
      LocalCache\Local\Codex\Logs\YYYY\MM\DD\
   
      Find "Current reported app-server version" and verify a successful initialization handshake. Do not read or print authentication tokens.
   
   3. Launch ChatGPT with its package identity preserved and a temporary localhost debugging listener:
      --remote-debugging-address=127.0.0.1
      --remote-debugging-port=19227
   
      Verify the port is free first. The method that worked was:
      Invoke-CommandInDesktopPackage
        -PackageFamilyName OpenAI.Codex_2p2nqsd0c76g0
        -AppId App
        -Command <Windows PowerShell executable>
        -Args <hidden PowerShell invocation that launches the installed ChatGPT.exe with those arguments>
   
      Keep the helper PowerShell window hidden. Do not launch the packaged executable directly as administrator; that produced “The process has no package identity.”
   
      If needed, CODEX_MAX_LOG_LEVEL=trace can be set in the launch helper’s process environment only. Do not set it persistently.
   
   4. Connect to http://127.0.0.1:19227/json/list and select the CDP page whose URL is:
      app://-/index.html
      Do not select detached-window.html.
   
   5. Inspect the renderer read-only through CDP:
      - Runtime.enable and Log.enable for errors.
      - window.__codexRoot._internalRoot.current for the React tree.
      - Locate the component responsible for displaying the startup spinner.
      - Inspect its readiness inputs and the relevant initialization code.
   
      Useful details from the affected build:
      - Spinner gate component: Jui
      - Its application scope was:
        gateFiber.updateQueue.memoCache.data[0][0]
      - Module variable fui: gateway readiness selector
      - Module variable gh: backend-version selector, parameterized by "local"
      - Module variable Xf: authentication state
      - Module variable kd: app-access state
      - Module variable Woe: existing backend-initialization handler
   
      These are minified names and MUST be verified against the installed build rather than blindly reused.
   
      To inspect module bindings:
      obtain the gate’s function object with Runtime.evaluate;
      use Runtime.getProperties to inspect [[Scopes]];
      inspect the Module scope and select only relevant variables.
   
   6. Confirm the exact condition before changing memory:
      scope.get(fui) === "loading"
      scope.get(gh, "local") == null
      authentication loading is false
      ChatGPT authentication/token-presence checks pass
      app access is allowed
      the backend log reports a successful handshake and an actual version
   
      In the previous build, readiness stayed loading specifically because the backend-version selector returned null.
   
   7. Inspect the existing initialization handler before invoking it.
      In the affected build, Woe pointed to this function:
   
      function TVr(scope, {
        appServerVersion,
        hostId,
        installedCodexVersion
      }) {
        const state = scope.get($V, hostId);
        scope.get(BVr, hostId).setAppServerVersion(appServerVersion);
        state.appServerVersion$.set(appServerVersion);
        if (installedCodexVersion !== undefined)
          state.installedCodexVersion$.set(installedCodexVersion);
      }
   
      Invoke that existing function through Runtime.callFunctionOn,
      passing the actual application scope and the backend version
      verified from THIS launch:
   
      handler(scope, {
        hostId: "local",
        appServerVersion: verifiedBackendVersion
      });
   
      Do not replace application code, force readiness/authentication flags,
      or fabricate a version. Stop if the condition or handler differs.
   
   8. Verify:
      - gateway readiness becomes "ready";
      - the main interface appears, including “Home” and “New chat”;
      - the window is no longer showing only the spinner.
   
   9. Disconnect the CDP client and LEAVE THE WORKING APP OPEN.
      Do not restart it as cleanup: restarting removes the workaround.
      Explain that the localhost debugging listener remains active until
      this diagnostic instance fully exits.
   
7. lucasar-web commented on Sep 26, 2026

   

   lucasar-web

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected PC: 26.924.1866.0 / Windows 11 25H2 26200.9457

   Adding an independent report, prepared with Codex diagnostic assistance and posted at the user's request. After the latest app update, the window stays indefinitely on the startup logo. The bundled CLI works when launched with --no-daemon.

   Environment verified on 2026-09-26

   • Store/MSIX package: OpenAI.Codex_26.924.1866.0_x64__2p2nqsd0c76g0; package status OK, not partially staged.
   • Windows 11 Home 25H2 x64, build 26200.9457.
   • App-server reports 0.158.0-alpha.2.
   • GPU: AMD Radeon RX 7800 XT; driver 32.0.31041.1004.
   • Windows Hang events identify ChatGPT.exe file version 154.0.8037.57.

   Observed startup sequence (2026-09-26, UTC; selected log fields)

   • 07:49:44.484: initialization handshake succeeds in 97 ms; Codex CLI initialized.
   • 07:49:44.486: app-server connection reaches connected.
   • 07:49:44.524: main frame finished load.
   • 07:49:44.609: primary window ready-to-show.
   • 07:49:44.644: host startup critical-path phases completed.
   • 07:49:45.539: React root render requested.
   • 07:49:46.341: ChatGPT account lookup succeeds, authenticatedAccountPresent=true.
   • Config, account, feature-list and requirements RPCs return errorCode=null.
   • 07:49:49.024: ChatGPT pubsub transport opens; notifications continue arriving later.
   • 07:54:44.129: updater policy times out, then Store update checking completes with NoUpdates.
   • Requirements RPCs still succeed at 07:59:49 and 08:04:50.
   • App-server transport stops at 08:09:02; EPIPE/reset warnings occur during teardown.

   The approximately 19-minute launch contains no [startup][renderer] app routes mounted entry. Read-only inspection confirmed that this marker still exists in the installed renderer code. This locates the incomplete startup stage but does not establish the underlying cause.

   Other checks

   • Windows recorded multiple Application Hang (1002) / WER MoAppHang (1001) events for this package earlier that morning.
   • config.toml parses successfully and contains zero NUL bytes. The global-state JSON and checked Chromium preference JSON files parse successfully.
   • SHA-256 hashes of the copied codex.exe, codex-code-mode-host.exe, codex-command-runner.exe and codex-windows-sandbox-setup.exe exactly match their bundled package counterparts.
   • No CODEX_CLI_PATH override was found in process/user/machine environment.
   • Disk space is sufficient. No related display/GPU/WHEA errors were found in the inspected System event sample.
   • The Artifact Session Unix-socket warning is caught by the installed code and startup continues afterwards.

   Scope and request
   This is retrospective log analysis of user-observed failed launches. The GUI was no longer running at the process snapshot; no new GUI reproduction or live renderer-state inspection was performed. The null backend-version state and memory-only workaround described above have NOT been verified on this PC.

   No reset, reinstall, cache clearing, authentication changes, process termination, or project/session-data edits were performed as part of this investigation. Conversation contents, tokens, account identifiers, private paths, raw dumps and full logs are intentionally excluded.

   Please investigate the missing renderer initialization/ready transition and provide a supported recovery or fixed app version that preserves existing history. The shared Windows build is context, not evidence that Windows itself is the root cause.
8. raf-uwt commented on Sep 26, 2026

   

   raf-uwt

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Reposting the diagnostic from my preferred GitHub account.

   Additional reproduction on Windows x64 / OS build 10.0.26200.

   Current Store package during the latest tests:

   • OpenAI.Codex 26.924.2738.0
   • Get-AppxPackage status: Ok
   • Earlier the same machine reproduced on 26.924.1866.0

   Key finding: the startup hang is reproducibly tied to the presence of ~/.codex/config.toml, not to any specific TOML setting.

   • Full generated config present -> hangs on splash/loading spinner.
   • Removing only the generated notify line -> still hangs.
   • Removing the entire [mcp_servers.node_repl] block -> still hangs.
   • Minimal config containing only [desktop] and [windows] settings -> still hangs.
   • A valid 0-byte config.toml -> still hangs.
   • Removing config.toml entirely -> Codex opens successfully.
   • After a successful launch, Codex recreates config.toml; after closing, the next normal launch hangs again.

   Failed-launch milestones on 26.924.2738.0:

   • initialize_handshake_result outcome=success
   • Codex CLI initialized
   • app-server reaches connected
   • main frame finished load
   • window ready-to-show
   • React root render requested
   • config/read succeeds with errorCode=null
   • account lookup succeeds with authenticatedAccountPresent=true and result=succeeded
   • later config/requirements RPCs continue succeeding
   • no [startup][renderer] app routes mounted milestone before the UI remains stuck

   The Artifact Session Unix-socket warning appears nonfatal because startup proceeds and the backend initializes successfully.

   Safe workaround:

   • stop ChatGPT/Codex processes
   • move/rename only ~/.codex/config.toml
   • launch via shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App
   • sessions/history remain untouched and the app opens successfully

   This suggests an existing-config/profile bootstrap path is preventing the renderer from completing startup, even when config.toml is empty. Please investigate the renderer initialization path for existing profiles/configs.

   👍React with 👍1Reacted by Darius Buinovskij