Skip to content

[Windows][26.924.22138] Desktop app stuck on loading spinner at startup; home only loads after codex.exe (app-server) is restarted #49240

Open
Open
[Windows][26.924.22138] Desktop app stuck on loading spinner at startup; home only loads after codex.exe (app-server) is restarted#49240
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@matcha186
matcha186
opened on Sep 29, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.924.22138

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Since the update to 26.924.22138 (around 2026-09-27), the Windows desktop app shows the logo and then an infinite loading spinner on every launch. The home screen never appears. Repair/Reset from Windows Settings does not help, and there are no error dialogs.

The desktop log records:
name=app_start outcome=failure reason=timeout initialSurface=home (~122 s)
[startup][renderer] app routes mounted is never logged in failing launches.

The app-server itself appears healthy: authentication, config/read, skills/list and thread/list requests are received, and model fetches return 200. The local SQLite databases pass PRAGMA quick_check.

Workaround (confirmed): while the spinner is showing, end the codex.exe process under the app in Task Manager. The app restarts the app-server and the home screen appears within a couple of seconds. This is required on every launch.

Observations:

  • In the only launches where home appeared, an app-server restart happened first (after the initial login, or after the first-run plugin install with a fresh CODEX_HOME). app routes mounted was logged within ~1 s after app_server_restart_recovery_done, and the restart log showed pendingClientRequests=1.
  • With a fresh CODEX_HOME, the first launch works (because of that restart), but every following launch hangs again, regardless of config.toml contents.

This suggests that one renderer→app-server request made during startup never resolves on the first connection, and only succeeds when it is re-sent after an app-server restart.

Versions: Store package OpenAI.Codex 26.924.2738.0 / app-server 0.158.0-alpha.2.1

What steps can reproduce the bug?

  1. Update the Windows desktop app to 26.924.22138.
  2. Launch the app → the logo appears, then an infinite loading spinner.
  3. Open Task Manager, expand the app's process group and end codex.exe.
  4. The app restarts the app-server and the home screen appears within a few seconds.
  5. Close and relaunch the app → the spinner appears again (reproduces on every launch).

What is the expected behavior?

The home screen should load normally on launch without having to kill the app-server process.

Additional information

The issue started right after the update from 26.924.20706 to 26.924.22138; the previous version launched normally with the same data. I can provide the desktop logs (LocalCache\Local\Codex\Logs) privately if needed.

Activity

  1. matcha186
    added
    appIssues related to the Codex desktop app
    on Sep 29, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Sep 29, 2026

  3. github-actions commented on Sep 29, 2026

    @github-actions
    github-actionsbot
    on Sep 29, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. ilhancakmak06 commented on Sep 29, 2026

    @ilhancakmak06
    ilhancakmak06
    on Sep 29, 2026 – with ChatGPT Codex Connector

    I can reproduce the same cold-start loading-screen hang on the newer Windows build.

    Environment:

    • Windows 11 Home, 10.0.26200, x64.
    • Desktop app 26.928.20755, build 12246; Microsoft Store package OpenAI.Codex 26.928.1915.0.
    • Bundled app-server 0.159.0.

    Reproduction/workaround: fully quit with Ctrl+Q and relaunch. The UI remains loading even though the local app-server initializes and authentication succeeds. Ending the app-server codex.exe in Task Manager lets the app create a new connection, and the interface appears within a few seconds. Closing the window alone can leave the app running in the tray. Changing the Windows default browser from Chrome to Edge did not resolve the startup hang. Disabling extensions also did not resolve it, according to my earlier troubleshooting.

    Measured launches on 2026-09-30 (UTC+03:00):

    • 01:28: app_start timed out at 132.371 s.
    • 01:30: app_start succeeded at 76.986 s, after an app-server restart.
    • 01:37: app_start succeeded at 86.810 s, again after restart. Renderer ready at 2.865 s, settings ready at 3.242 s, shell visible at 86.611 s, sidebar ready at 86.810 s.
    • 02:01: app_start timed out at 177.791 s wall time, including 55.709 s while the window was in the background. Renderer/host/settings were ready within about 2–3 s; shell/sidebar readiness marks were absent at timeout.

    In the 01:37 launch, the first initialize handshake took 182 ms; the connection became connected 6 ms later. account/read took 8 ms, getAuthStatus 15 ms, and the initial account lookup succeeded. At 01:37:49, local codex_app tools/list timed out after 10 s. The app-server connection closed at 01:38:55.768 with code 4294967295 (-1), reconnected at 01:38:56.006, and app_start completed at 01:38:57.866. The -1 exit should not be assumed to be a spontaneous crash: manual Task Manager termination is the workaround used here. The close message attaches the previous tools/list warning; it is not a crash stack.

    A separate Norton HTTPS inspection problem caused malformed HTTP chunk framing for codex_apps. A chatgpt.com exception eliminated that decoding error; subsequent launches show codex_apps ready and zero decoding errors, while this loading-screen problem remains. An independent authenticated bootstrap request also returned a complete valid JSON response in about 1.9 s. No current RAM/commit exhaustion was observed.

    This supports investigating initial-connection state synchronization or an unresolved startup dependency, as also discussed in #49237. A missed one-time readiness notification remains a hypothesis, not something the logs directly prove. Please investigate startup state replay/recovery and whether a fix is planned. No feedback-upload session ID has been generated yet.

    Follow-up: a more specific renderer/main state mismatch is visible in four launches on the same build.

    The main process records the initial LOCAL connection as connected, but the renderer does not record a LOCAL connected transition at that point. It does process the separate durable connection. The renderer's first LOCAL event is the error caused by the manual app-server termination; its manager logs previousState=disconnected. Only the replacement connection reaches LOCAL connected in the renderer.

    Examples (2026-09-30, UTC+03:00):

    • 02:01 launch: main LOCAL connected at 02:01:06.037; renderer durable connected at 02:01:13.325. First renderer LOCAL event: error at 02:04:18.564, previousState=disconnected. Renderer LOCAL connected at 02:04:18.871 after restart.
    • 02:15 launch: main LOCAL connected at 02:15:34.898; renderer durable connected at 02:15:42.136. First renderer LOCAL event: error at 02:15:48.363, previousState=disconnected. Renderer LOCAL connected at 02:15:48.636 after restart; full app_start at 02:15:50.305.
    • The 02:13 and 02:14 launches show the same main-connected / renderer-local-disconnected sequence. Those three shorter starts are manual-intervention observations, not evidence of an unattended fix.

    These transitions are logged through remote_connections.connection_state_changed / remote_connections.manager_state_set. In the long 02:01 launch, config/read calls also completed in 11–48 ms and configRequirements/read in 2 ms, so a permanently pending initial configuration read is not supported for that launch.

    Read-only inspection of the installed bundle shows intended connection/initialize snapshot replay on webview registration and ready. Connection and initialized messages are not among the renderer MessageBus's buffered request/response message types. This narrows the investigation to why the initial LOCAL state is not reflected in the renderer despite the replay path. It does not yet identify the exact lost IPC message or prove a particular subscription-order defect.

  5. hanzoua commented on Sep 30, 2026

    @hanzoua
    hanzoua
    on Sep 30, 2026 – with ChatGPT Codex Connector

    Additional reproduction on a newer Windows build:

    • Installed package: OpenAI.Codex 26.928.2636.0
    • Windows x64
    • Full uninstall/reinstall performed
    • Reproduces with a completely fresh .codex

    Reproduction:

    1. Rename/remove .codex.
    2. Launch Codex and sign in — first launch succeeds.
    3. Fully exit the app.
    4. Launch again — app remains indefinitely on the animated logo/loading screen.
    5. While the window is still open, terminate only the child codex.exe ... app-server process.
    6. Desktop immediately recovers and loads normally.
    7. Exit and relaunch — the problem reproduces again.

    This appears independent of existing projects/chat history. I restored my full old .codex with all projects and conversations; the same workaround immediately restores the UI, and the existing chats work normally afterward.

    After recovery, an existing chat successfully executed a normal task including git commit and git push, so authentication and normal Codex operation appear healthy after the app-server restart.

    The app-server process can be identified as a child of ChatGPT.exe whose command line contains app-server.

    Workaround used:

    Get-CimInstance Win32_Process -Filter "Name='codex.exe'" |
Where-Object {
    $_.CommandLine -match 'app-server' -and
    (Get-Process -Id $_.ParentProcessId -ErrorAction SilentlyContinue).ProcessName -eq 'ChatGPT'
} |
ForEach-Object {
    Stop-Process -Id $_.ProcessId -Force
}

    The UI loads immediately after the initial app-server is terminated and respawned.

    This looks like a cold-start / first app-server initialization issue rather than corrupted chat/project data.

  6. piyushwwe6-cell commented on Oct 1, 2026

    @piyushwwe6-cell
    piyushwwe6-cell
    on Oct 1, 2026

    I reproduced this on Windows 11 with OpenAI.Codex 26.928.2636.0. Updating, Windows Repair/Reset, and testing another internet connection did not resolve the startup hang.

    Keeping the ChatGPT window open and stopping only its child codex.exe app-server process cleared the loading screen when the app restarted that process automatically.

    Thanks for documenting this workaround. This confirms UI recovery on this version; I haven't separately verified task submission or a permanent fix.

  7. potok787 commented on Oct 1, 2026

    @potok787
    potok787
    on Oct 1, 2026

    у меня тоже проблема с зависанием при запуске, задолбала уже, сам чат не может разобраться, уже 3 часа меня своими советами и диагностиками мучает и ничего так и не решилось.
    версия 26.928.3736.0 и Windows 11, сборка 26200, дополняют уже опубликованные отчёты.

  8. potok787 commented on Oct 1, 2026

    @potok787
    potok787
    on Oct 1, 2026

    вот какие выводы сделал чат. По результатам наших проверок наиболее вероятна ошибка настольного приложения OpenAI, связанная с взаимодействием интерфейса ChatGPT и внутреннего процесса Codex.
    Мы воспроизвели её несколько раз: браузер работает, смена сети и создание нового профиля не помогают, а завершение codex.exe app-server немедленно восстанавливает приложение.
    Однако точная программная причина ещё не доказана. Это может быть ошибка последовательности запуска компонентов или несовместимость конкретной версии с твоей конфигурацией Windows. Неисправность серверов OpenAI нашими проверками не подтверждается.

  9. potok787 commented on Oct 1, 2026

    @potok787
    potok787
    on Oct 1, 2026 – with ChatGPT Codex Connector

    Additional structured report for @potok787 (Windows 11 Pro Education, build 26200; installed Microsoft Store package OpenAI.Codex 26.928.3736.0), following the earlier comments above:

    • The Windows desktop UI hangs indefinitely both on cold startup and, on some occasions, after submitting a new agent task. The web ChatGPT interface works.
    • Reproduced after restarting the PC/app, switching to a mobile hotspot, attempting Windows app repair, and renaming the packaged app's web profile (%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex) to force a fresh profile. The new profile did not resolve the hang. The original profile was backed up rather than deleted.
    • While the loading spinner is displayed, terminating only codex.exe whose command line contains app-server causes the desktop UI to recover. The issue returns after a subsequent launch; the workaround is not a permanent fix.
    • A Windows diagnostic report did not show relevant Application event errors, but that does not rule out application-level failures. We have not yet captured a /feedback session ID because task submission itself may hang.

    This closely matches the initial LOCAL connection / renderer state discrepancy documented earlier in this thread, though that mechanism has not been verified against this user's own desktop logs. Could a maintainer confirm whether engineering is tracking this as a first-connection initialization defect, identify the exact non-sensitive log files/fields needed to distinguish it from other startup failures, and indicate whether a fixed build or safe permanent workaround is available? We can provide sanitized desktop logs privately if an official secure channel is supplied; session transcripts and authentication tokens should not be posted publicly.

  10. ArcSeil commented on Oct 2, 2026

    @ArcSeil
    ArcSeil
    on Oct 2, 2026 – with ChatGPT Codex Connector

    Additional reproduction on Windows after a clean OS reinstall.

    Codex app version: 26.928.4866.0

    Reproduction:

    1. Clean Windows installation.
    2. Install Codex/ChatGPT desktop app.
    3. App opens initially and allows sign-in.
    4. After sign-in or after closing/relaunching the app, it becomes stuck indefinitely on the OpenAI logo.
    5. Reinstalling the app temporarily allows one successful launch, but the issue returns.
    6. Renaming/resetting .codex, AppX LocalCache/LocalState, plugins, and models_cache.json does not permanently fix the issue.
    7. While the app is stuck on the logo, running:
    Get-Process codex -ErrorAction SilentlyContinue |
Stop-Process -Force

    causes the backend/app-server to restart and the UI loads normally.

    This workaround has been reproduced multiple times.

    The issue persisted across app versions 26.928.3736.0 and 26.928.4866.0.

    This strongly suggests a startup/app-server initialization or reconnect issue rather than corrupted user data.

  11. piotrrawski80 commented on Oct 2, 2026

    @piotrrawski80
    piotrrawski80
    on Oct 2, 2026 – with ChatGPT Codex Connector

    I can reproduce this on Windows 11 x64 (NT 10.0.26200) with the newer unified ChatGPT/Codex desktop package.

    Environment:

    • ChatGPT Plus
    • OpenAI.Codex Store package: 26.928.3736.0
    • Codex CLI: 0.160.0 (CLI works normally)
    • ChatGPT Classic works; the new ChatGPT app (OpenAI.Codex package) hangs on the OpenAI logo/loading screen

    Observed behavior:

    • Startup can hang indefinitely on the logo.
    • Killing only the child codex.exe ... app-server process has repeatedly caused the UI to continue loading, but the problem can return later (including after submitting a prompt), so this is only a temporary workaround.
    • Reset-AppxPackage did not fix it.
    • Reinstall/update attempts via Microsoft Store / winget did not fix it; Store currently reports no newer package for this account/region.
    • Resetting .codex configuration did not fix it.
    • Disabling codex-app-tools / code-review plugins did not fix it.
    • Auth and local Codex databases check healthy; CLI connectivity works.

    Relevant desktop log evidence captured during the hang:

    • name=app_start outcome=failure reason=timeout (~123s)
    • Codex app-server websocket is not open
    • Codex app-server websocket closed (code=1006) followed by reconnect attempts
    • local stdio app-server startup/initialize handshake can succeed before the UI still hangs
    • occasional Desktop network policy does not allow this destination for internal account/onboarding requests

    This looks extremely close to the issue described here, but it persists on 26.928.3736.0 and affects the current unified ChatGPT desktop app. Please treat this as confirmation that the startup/app-server issue is still present in later Windows builds. I can provide a sanitized diagnostic log if maintainers need it.

  12. piotrrawski80 commented on Oct 2, 2026

    @piotrrawski80
    piotrrawski80
    on Oct 2, 2026 – with ChatGPT Codex Connector

    Fresh reproduction on OpenAI.Codex 26.928.3736.0 / Windows 11 build 10.0.26200. The new ChatGPT app is stuck indefinitely on the OpenAI logo.

    This launch shows both local stdio and durable websocket handshakes succeeding:

    • local app-server 0.159.2: initialize_handshake_result ... outcome=success transportKind=stdio
    • durable app-server 0.1.0: initialize_handshake_result ... outcome=success transportKind=websocket
    • host startup critical path completed in ~970 ms
    • durable websocket reached next=connected
    • websocket_reconnect_recovery_done completed successfully

    Despite that, the renderer never reaches the usable home UI. After ~161 s the app emits:
    name=app_start outcome=failure reason=timeout
    with marks showing renderer_ready, host_startup_ready, and settings_ready all completed within ~3 s.

    This is important because it shows the hang can reproduce even when the durable websocket is healthy and connected. So the failure is not solely explained by the earlier 1006 / websocket is not open condition. It appears to be a later bootstrap/UI progression failure after renderer/settings readiness.

    Current local CLI is 0.160.0. Reset-AppxPackage, config reset, disabling codex-app-tools/code-review, and reinstall/update checks did not resolve the issue. Microsoft Store still serves 26.928.3736.0 to this account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions