Skip to content

Desktop app stuck on infinite loading spinner on Windows (26.924.2738.0); renderer never mounts #49008

Closed
Closed
Desktop app stuck on infinite loading spinner on Windows (26.924.2738.0); renderer never mounts#49008
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@drluisbarrios
drluisbarrios
opened on Sep 28, 2026

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

26.924.2738.0

What subscription do you have?

Team plan

What platform is your computer?

Windows 11 Core 10.0.26200, x64

What issue are you seeing?

Codex Desktop on Windows 11 shows an infinite loading spinner (black screen with logo).
The window is responsive at the OS level but never renders the UI.

Codex Desktop, Store package OpenAI.Codex 26.924.2738.0 (internal app_version 26.924.22138)

  • Backend: codex 0.158.0-alpha.2.1
  • Windows 11 Core 10.0.26200, x64
  • Account: ChatGPT team plan

What steps can reproduce the bug?

What is healthy

  • codex login status returns "Logged in using ChatGPT".
  • codex doctor: state databases healthy, config parse ok, auth configured, install consistent.
  • The backend returns 200 OK for GET https://chatgpt.com/backend-api/codex/models?client_version=0.158.0
    repeatedly while the UI is stuck.
  • All HTTP requests logged by the renderer return 200, 202 or 204. No 4xx/5xx.

Renderer errors (from sentry/scope_v3.json)

[electron-message-handler] Request failed conversationId=none durationMs=5
  error={"code":-32603,"message":"The system cannot find the path specified. (os error 3)"}
  method=fs/readFile pendingCountAfter=1 priority=interactive source=filesystem

[electron-message-handler] Conversation state not found
  conversationId=01a0d90e-e035-7891-88c8-4ce750a10bc6

Matched leaf route at location "/" does not have an element or Component.
This means it will render an <Outlet /> with a null value by default
resulting in an "empty" page.

What is the expected behavior?

Steps tried with no result

  1. Graceful quit and relaunch.
  2. Removal of stale temporary artifacts in ~/.codex.
  3. Reset-AppxPackage for the MSIX package.
  4. The WSL agent-environment workaround is not applicable: the Settings screen is
    unreachable because the UI never renders, and the only WSL distribution present is
    docker-desktop (stopped).

Additional information

Timing

The package updated to 26.924.2738.0 and the app started 2 seconds later. The problem began
with that launch and has persisted across every restart since.

Request

Any way to pin or roll back to the previous package version while this is investigated.

Activity

  1. drluisbarrios
    added
    appIssues related to the Codex desktop app
    on Sep 28, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Sep 28, 2026

  3. github-actions commented on Sep 28, 2026

    @github-actions
    github-actionsBot
    on Sep 28, 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. pipthefirstagent commented on Sep 30, 2026

    @pipthefirstagent
    pipthefirstagent
    on Sep 30, 2026

    Same issue here, with a few extra data points that may help narrow it down.

    Build: package 26.928.1915.0 · app 26.928.20755 · bundled codex-cli 0.159.0 · Windows 11 Pro 10.0.26300 x64
    Feedback ID: no-active-thread-01a0f0c4-76bf-7da1-b733-7060bee3dea0

    Account-specific:

    • Personal Pro Lite account (no workspace): every cold start hangs on the logo.
    • Team-workspace account on the same PC: works normally.
    • Signing out and back in with the Personal account works for that one session; the next cold start hangs again.
    • On the first hangs, the renderer logged Matched leaf route at location "/" does not have an element or Component and [Statsig] The user does not have the required id_type "workspace_id".

    Hung cold start (log attached, 05:20:05–05:20:23Z):

    • App-server codex.exe processes spawn once and keep running, with no exit/restart loop.
    • At startup+18s: mcp_extension_tool_discovery_failed ... error="MCP startup failed: timed out awaiting tools/list after 10s" pluginId=codex-app-tools@openai-bundled server=codex_app
    • After that the log is silent. No retry, and the UI stays on the logo indefinitely.
    • Killing codex.exe gets past the logo, but the UI comes up half-loaded (Desktop network policy does not allow this destination on /accounts/check and /wham/onboarding/context, Authenticated workspace changed on /settings/user).

    Ruled out: cleared web cache, Store Repair/Reset, fresh CODEX_HOME, sandbox elevated↔unelevated, network/DNS/proxy (codex doctor: 0 failures; websocket 101; endpoints reachable). No Store update available.

    Also: gpt-6-astra is missing from the desktop model picker, but works via codex exec -m gpt-6-astra and on chatgpt.com with the same account.

    EDIT:

    Follow-up: found a reliable workaround, which suggests the hang is in startup auth/session reuse rather than connectivity.

    1. Quit the app fully (ChatGPT.exe + codex.exe).
    2. Move %USERPROFILE%\.codex\auth.json out of the folder temporarily.
    3. Start the app. With no cached auth it renders the sign-in screen (no logo hang).
    4. After ~10 s, put auth.json back and end codex.exe.
    5. The app-server restarts, picks up the cached login, and the UI loads fully: projects, chat history, composer. It stays stable afterwards.

    So on this build (26.928.1915.0 / app 26.928.20755 / codex-cli 0.159.0), with a Personal Pro Lite account:

    • cold start with cached auth → hangs on logo (after codex_app tools/list 10 s timeout, no retry)
    • cold start without cached auth → renders fine; injecting the same cached auth afterwards → works

    The account, tokens and network are fine. The renderer appears to deadlock when cached auth is present at startup for a non-workspace account. (Team-workspace accounts don't hang.)

  5. ideliek commented on Sep 30, 2026

    @ideliek
    ideliek
    on Sep 30, 2026

    Same symptom here on Windows 11, app 26.928.2636.0 (also seen on 26.928.1915.0 and 26.924.2738.0).

    In-app feedback ID: no-active-thread-01a0f3ad-4188-7940-b3e3-0a68ee4251b7

    Adding two things I haven't seen mentioned in this thread yet: a working workaround, and a measurement that narrows down where it hangs.

    The renderer is alive but empty — a forced reload recovers it

    With the app stuck on the loading screen, I attached to the renderer via CDP:

    • document.querySelectorAll('*').length → ~58 nodes, no visible text
    • Page.reload(ignoreCache=true) on app://-/index.html → 2000+ nodes, full UI appears, chats and projects usable

    So the document loads fine; app initialisation gets stuck afterwards, and a forced reload gets it out of that state. This is reproducible and is now my daily workaround (a launcher that reloads the renderer if the UI doesn't come up).

    Startup telemetry

    name=app_start outcome=failure reason=timeout        (~122000 ms)

marksMs = { renderer_entry_evaluated ~2500,
            host_services_ready      ~2500,
            renderer_ready           ~2700,
            host_startup_ready       ~2700,
            settings_ready           ~3100 }   <-- last mark reached

    shell_visible, home_visible and sidebar_ready are never emitted, and app routes mounted ... rendererWindowAppearance=primary is absent. The gap is therefore between settings_ready and shell_visible.

    The backend is healthy — this is purely the frontend

    • The app-server answers thread/list, config/read, app/read and starts MCP servers normally during the very same failing runs.
    • The codex CLI works flawlessly with the same CODEX_HOME and the same auth.
    • Remote control from a phone works while the desktop UI is stuck on the loading screen.

    Frequency

    Intermittent: 21 of 77 logged startup attempts succeeded — same binary, same profile, no changes in between.

    Ruled out (each tested individually, non-destructively)

    • codex logout + codex login; token expiry verified via JWT exp
    • Profile data: thread history (748 MB), sessions/ (2.4 GB, 671 files), .tmp/ (10,457 files), .sandbox, sqlite/, vendor_imports/, skills/, cache/ — each moved aside; all SQLite DBs pass PRAGMA quick_check
    • Config: all 33 plugins, all 5 marketplaces, all 3 MCP servers, 23 [projects.*] entries, the model setting, and the SessionStart hooks of all plugins
    • winget repair of the Store app (completed successfully), update to 26.928.2636, Windows restart
    • Primary runtime rebuilt from scratch
    • Chromium code/GPU/shader caches cleared

    Two observations that may or may not be related

    • [windows] sandbox = "elevated" triggers a UAC prompt for codex-windows-sandbox-setup.exe on every launch. If it isn't answered, startup runs straight into the 122 s timeout — worth considering for unattended/automated starts.
    • Plugins disabled in the UI are re-enabled when the app rewrites config.toml (13 were switched back to enabled = true, including codex-app-tools, browser, chrome, computer-use, unified-computer-use, visualize).

    Happy to provide full logs if useful.

  6. drluisbarrios
    closed this as completedon Oct 10, 2026
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 appbugSomething 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