Skip to content

Windows ChatGPT app 26.924.2738.0 stuck on blank screen with endless loading spinner #49452

Open
Open
Windows ChatGPT app 26.924.2738.0 stuck on blank screen with endless loading spinner#49452
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Yam-W
Yam-W
opened on Sep 30, 2026

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

26.924.2738.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26300.0 x64

What issue are you seeing?

The Windows Codex/ChatGPT desktop app launches, but the main window remains blank with an endless loading spinner and never finishes loading.

Environment:

  • Codex App version: 26.924.2738.0
  • Package name: OpenAI.Codex
  • Architecture: x64
  • ChatGPT subscription: Plus
  • Login method: Google
  • The ChatGPT web app works normally on the same computer and account.

The application processes appear to launch normally. In Task Manager, the ChatGPT process group starts successfully together with multiple Codex processes and codex-windows-sandbox-service, but the UI remains stuck on the loading screen indefinitely.

I have already tried:

  • Force quitting and restarting the app
  • Repairing the app through Windows Settings
  • Resetting the app through Windows Settings
  • Uninstalling and reinstalling the app
  • Restarting Windows
  • Testing a different network/mobile hotspot
  • Disabling VPN/proxy
  • Checking that WebView2 is installed and functioning
  • Confirming the package status in PowerShell

PowerShell reports:

Name: OpenAI.Codex
Version: 26.924.2738.0
Status: Ok

There is no error message displayed in the UI.

Because the application never reaches the main interface, I am also unable to use the in-app "/" feedback mechanism suggested by OpenAI Support.

OpenAI Support advised me to capture diagnostic information and report the issue here.

Please let me know if there are specific log files, diagnostic bundles, or crash reports I can provide to help investigate this issue.

What steps can reproduce the bug?

  1. Launch the ChatGPT/Codex Windows desktop app.
  2. The application window opens normally.
  3. The main content area remains blank.
  4. A loading spinner appears in the center of the window.
  5. The spinner continues indefinitely and the application never reaches the main ChatGPT interface.

The issue reproduces every time the application is launched.

Additional observations:

  • The ChatGPT/Codex processes remain running in Task Manager.
  • The ChatGPT web app works normally on the same computer and account.
  • No error message is displayed.
  • Repair, Reset, reinstall, Windows restart, network change, and WebView2 checks did not resolve the issue.

What is the expected behavior?

The Windows desktop app should finish loading and display the normal ChatGPT interface, including the conversation sidebar and message composer, allowing me to use ChatGPT normally.

Additional information

No response

Activity

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

  3. github-actions commented on Sep 30, 2026

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

    @moruku36
    moruku36
    on Sep 30, 2026

    Workaround that worked for me (Windows 11, app 26.928.2636.0, MSIX)

    Same symptom here: the window opens and stays on the OpenAI-logo splash forever, ChatGPT.exe is responding, and codex.exe app-server is running. Re-registering the package (Add-AppxPackage -Register …\AppxManifest.xml) and clearing the GPU/shader caches did not help.

    What fixed it: leave the app open and kill only the backend codex.exe processes (not ChatGPT.exe). The app respawns them within a few seconds and the UI then loads normally (this matches #49447).

    Get-Process codex | Where-Object { $_.Path -like '*Codex*' } | Stop-Process -Force

    Looks like a startup race between the renderer and the app-server rather than a corrupted install. I haven't yet confirmed whether it recurs on the next launch, so I can't say if this is a one-time fix or needs repeating.

  5. Yam-W commented on Sep 30, 2026

    @Yam-W
    Yam-W
    on Sep 30, 2026
    Author

    Thanks for the workaround. I tested it after updating the Windows app to version 26.928.2636.0.
    The command to kill only the backend codex.exe processes while leaving ChatGPT.exe running does work partially:
    Get-Process codex | Where-Object { $_.Path -like 'Codex' } | Stop-Process -Force

    After running this command, the app respawns the backend processes and gets past the initial OpenAI-logo / loading-spinner screen.
    However, the app is still not fully usable afterward.
    Current behavior on my system:

    • Normal launch: the app gets stuck indefinitely on the OpenAI-logo / loading-spinner screen.
    • Killing only the backend codex.exe processes allows the main application shell and sidebar to load.
    • The left sidebar displays normally, including Projects and existing conversation titles.
    • Selecting any existing conversation leaves the main content pane completely blank.
    • Creating a new conversation also does not work; the main content pane remains blank.
    • The same account and conversations work normally in the ChatGPT web app on the same computer.
      I also tested launching the app with:
      --disable-gpu-compositing

    but this did not improve the situation. Instead, the app returned to the original startup behavior and became stuck on the loading spinner again.
    So on my system, restarting the backend codex.exe processes appears to resolve only the initial startup hang, but the main conversation/content area still fails to initialize or render.
    Environment:

    • Windows 11 x64
    • ChatGPT/Codex Windows app version: 26.928.2636.0
    • Package: OpenAI.Codex
    • ChatGPT Plus
    • Login method: Google
    • Web app works normally on the same machine/account
      If there are specific logs, diagnostic files, crash reports, or tracing steps that would be useful, I would be happy to provide them.

  6. lernicks0 commented on Oct 1, 2026

    @lernicks0
    lernicks0
    on Oct 1, 2026

    Same symptom on a different machine. Adding startup-timing and log evidence that may help
    pinpoint where it blocks — I was able to reproduce both the hang and a successful launch, so
    the two can be compared.

    Environment

    Item Value
    Package full name OpenAI.Codex_26.928.3736.0_x64__2p2nqsd0c76g0
    Internal version string 154.0.8037.57 (as reported in Windows Application Hang events)
    App-server version 0.159.2
    OS Windows 11, build 10.0.26200 x64
    CPU / GPU i5-13600KF / RTX 4070 SUPER (driver 596.21)
    Locale zh-CN (2052)

    Note: the app is intermittent here — sometimes it reaches the UI, sometimes it sits on the
    loading screen forever. That differs from the original report (always failing), and might make
    it easier to bisect.

    Startup sequence (identical in both the hanging and the successful launches)

    Codex CLI initialized
window main frame finished load appearance=primary hostId=local
window ready-to-show appearance=primary hostId=local
React root render requested rendererWebContentsId=1
window main frame finished load appearance=detached hostId=local
window ready-to-show appearance=detached hostId=local

    So the renderer starts and the React root is requested — the UI just never becomes usable.

    Blocking signals found in the logs

    Log path:
    %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<yyyy>\<MM>\<dd>\codex-desktop-*-t0-*.log

    1. MCP tool discovery times out on every launch

    warning [electron-message-handler] mcp_extension_tool_discovery_failed
  authStatus=unsupported
  error="MCP startup failed: timed out awaiting tools/list after 10s"
  hostId=local

    The MCP server config declares startup_timeout_sec = 120, but the client gives up after 10 s.
    This occurs on every launch, including with a fresh install, reset package data, and an empty
    config.toml — so it is not caused by user MCP configuration.

    2. The durable app-server host takes 21–85 seconds to connect

    [AppServerConnection] Starting app-server connection hostId=durable transport=websocket
[AppServerConnection] app_server_connection.connection_failed_before_ready
  errorMessage="WebSocket was closed before the connection was established"
[AppServerConnection] app_server_connection.closed code=1006 failureReason=open_timeout
[AppServerConnection] app_server_connection.reconnect_scheduled
  reconnectAttempt=2 nextDelayMs=4000
...
[electron-message-handler] remote_connections.manager_state_set
  hostId=durable nextError=null nextState=connected

    Measured from process start to nextState=connected:

    Launch Time to durable connected
    Launch A 85 s
    Launch B 21 s

    The reconnect backoff climbs (2s → 4s → 8s → 16s → 20s), so one slow/failed first attempt
    pushes the wait out past a minute.

    3. An authenticated renderer GET returns 404 on every launch

    warning [electron-message-handler] sa_server_request_failed
  attachAuth=true attachIntegrityState=true
  errorMessage="{\"detail\":\"Not Found\"}"
  errorStack="Error: {"detail":"Not Found"}
    at bmn (app://-/assets/app-shared-7552fc8d5d82.js:484:72576)
    at async e.fetch ... at async e.fetchJson ... at async $mn.makeRequest ..."
  hasRequestBody=false method=get
  rendererWebContentsId=1 rendererWindowVisible=true

    Also occurs on a clean install, so it is not local-state corruption either.

    Ruled out (with evidence)

    • No renderer crash — the Crashpad directory contains no dumps.
    • No error-level entries in the main process log (] error count = 0).
    • Local app-server is healthy — config/read, account/read, fs/readFile all return
      response_routed ... errorCode=null.
    • GPU process is alive (--type=gpu-process child present); other Chromium apps (Chrome,
      Edge WebView2) render fine on the same desktop.
    • Network is fine — OpenAI endpoints are reachable (api.openai.com/v1/models → HTTP 401),
      and the Cloudflare challenge that previously intercepted requests no longer appears.

    Troubleshooting already attempted

    Action Result
    Cleared GrShaderCache, ShaderCache, GPUCache, Dawn*Cache (~24 MB) No change
    Reset the app web data directory (586 MB) No change
    Reset-AppxPackage (package data 850 MB → 0) No change
    Re-registered the package via Add-AppxPackage -Register ...AppxManifest.xml No change
    Removed all [mcp_servers.*] from config.toml MCP timeout persists (bundled plugins); no change
    Launched with --disable-gpu via IApplicationActivationManager Electron ignored the switch (gpu-process still spawned)
    Killed the NVIDIA overlay / container processes No change
    NVIDIA driver 591.86 → 596.21 + reboot No change
    Fixed local DNS pollution and proxy routing No change to the hang

    Suggestions

    1. Do not gate the main UI on MCP tool discovery or on the durable host connection.
      Paint the shell immediately and surface those subsystems as background status with retry.
    2. Honour startup_timeout_sec from config.toml instead of a hard-coded 10 s.
    3. Show the current startup phase and last error on the loading screen instead of an
      indefinite spinner — that alone would have made this report unnecessary.
    4. Bound the durable connect attempt so one slow attempt cannot stall startup for 85+ s.
    5. Look into the recurring authenticated {"detail":"Not Found"} 404 on the sa_server GET.

    Happy to provide full codex-desktop-*-t0-*.log files for both a hanging and a successful
    launch, plus config.toml (redacted) and nvidia-smi / dxdiag output, if that helps.

  7. lernicks0 commented on Oct 1, 2026

    @lernicks0
    lernicks0
    on Oct 1, 2026

    Addendum — root cause located: the startup "primary runtime" install is what blocks the UI

    I managed to catch both a failing and a succeeding launch on the same machine, and the
    difference is a single operation. Posting the evidence here because it pinpoints exactly which
    step leaves the window on the endless spinner.

    The blocking operation

    When the app decides its primary runtime needs (re)installing, it performs a network
    download/verification during startup    . If that fails, the UI never leaves the loading
    screen     — no error, no fallback, no timeout that recovers:

    10:09:05.772 info  [install-primary-runtime] primary_runtime_selection
  architecture=x64 buildFlavor=prod runtimeSource=archive reason=gate-disabled
  runtimeRoot=C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime

10:09:15.104 info  [install-primary-runtime] primary_runtime_install_started
  trigger=startup_missing forceReinstall=false release=latest target=win32-x64

10:10:05.690 error [primary-runtime-installer] primary_runtime_bundle_install_outcome
  bundleVersion=26.909.11814 durationMs=50586
  errorMessage=net::ERR_CONNECTION_CLOSED

10:10:05.691 error [install-primary-runtime] primary_runtime_install_failed
  bundleVersion=26.909.11814 durationMs=50587
  errorMessage=net::ERR_CONNECTION_CLOSED

10:10:05.692 warning [install-primary-runtime] primary_runtime_update_poll_failed
  errorMessage=net::ERR_CONNECTION_CLOSED

    The UI stayed on the spinner for as long as the process lived. Relaunching did not help while
    the install kept failing.

    Correlation across four launches on the same machine

    Launch primary_runtime_install_started Install outcome Time UI
    A 1 failed — net::ERR_CONNECTION_CLOSED 50.6 s ❌ stuck on spinner forever
    B 1 succeeded 196 s ✅ loaded afterwards
    C 0 (already current) — — ✅ loads immediately
    D 0 (already current) — — ✅ loads immediately

    Every launch where the runtime install was skipped loaded fine. The only launch that hung
    is the one where the install failed. Once launch B completed the install successfully,
    launches C and D skip it entirely and start normally.

    This also explains the intermittency I reported earlier: the behaviour depends purely on
    whether the startup runtime install succeeds, not on anything in the profile or cache.

    A reliable reproduction path

    On my machine the failing launch was triggered by resetting the app, which clears the
    "runtime is installed" state and forces trigger=startup_missing:

    Reset-AppxPackage -Package <PackageFullName>
# then launch the app

    If the machine's network cannot complete the runtime bundle download, the app will sit on the
    loading spinner indefinitely. This may reproduce the "reproduces every time" case in the
    original report for users on restrictive networks, and would explain why an affected user's
    web app works fine (the web app needs no runtime bundle).

    For reference, the runtime directory itself was intact on disk
    (%USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime, ~1.3 GB) — so the failing step is
    the install/verification call, not a missing local payload.

    Impact

    1. No recovery path. A transient network failure during the runtime install permanently
      bricks the UI for that session, with no error surfaced to the user.
    2. Silent failure. The spinner gives no indication that a 1.3 GB download is in flight or
      that it failed.
    3. Very long blocking window. Even the successful install took 196 s. A user has no
      way to know they should wait rather than kill the app.
    4. Reset makes it worse. The documented remedy ("reset the app") strips the installed
      runtime state and forces the fragile download again.

    Suggestions

    1. Never gate the main UI on the primary runtime install. Render the shell and surface the
      runtime as background status ("preparing runtime… 42%"), with a retry action.
    2. Surface the failure. If the install fails, show the error and offer "Retry" / "Continue
      without runtime" instead of an indefinite spinner.
    3. Add resumable / retrying download with backoff. net::ERR_CONNECTION_CLOSED mid-download
      is common on unstable or proxied networks and should not be terminal.
    4. Do not let Reset-AppxPackage invalidate an on-disk runtime payload that is already
      present and valid under %USERPROFILE%\.cache\codex-runtimes\.
    5. Consider shipping the runtime bundled with the MSIX so first-run needs no large download.

    Workaround for other affected users

    • If the window is on the spinner, wait 3–5 minutes before killing it — a runtime install
      may be in flight. Killing it discards the progress and it restarts from zero next launch.
    • Once one launch completes the install, subsequent launches skip it and start immediately.
    • Avoid Reset-AppxPackage / "Reset" in Settings unless you can afford a fresh runtime install.
    • Keep the connection stable for the duration; avoid switching proxy nodes mid-install.

    Happy to provide the full codex-desktop-*-t0-*.log files for both launch A (hang) and launch B
    (success) if that helps.

  8. lernicks0 commented on Oct 1, 2026

    @lernicks0
    lernicks0
    on Oct 1, 2026

    Correction to my addendum above

    I need to walk back the "root cause" framing in my previous comment. After posting it I observed the
    same hang on a machine where the primary runtime install was not involved at all, so the
    runtime install failure is one way to end up on the endless spinner — not the general cause.

    The contradicting observation

    Fresh launch, same machine, same symptom (window stuck on a blank/loading screen, ~2 % of pixels
    drawn — i.e. just the small centered mark on white). Relevant log facts for that launch:

    Signal Value
    primary_runtime_install_started 0
    primary_runtime_install_failed 0
    [chatgpt-account-lookup] completed result=succeeded, authenticatedAccountPresent=true, authMethod=chatgpt, hasEverErrored=false
    remote_connections.manager_state_set hostId=durable nextState=connected
    websocket_reconnect_recovery_done present
    local app-server (config/read, getAuthStatus, fs/readFile) responds via response_routed, errorCode=null
    chatgpt_pubsub_transport_opened / topic_subscribed present
    error-level entries only two, both benign-looking (fs/readFile requires an environmentId, Conversation state not found)
    mcp_extension_tool_discovery_failed 1, pluginId=codex-app-tools@openai-bundled

    So on this launch every dependency I can observe from the logs reported success, the runtime
    bundle was already installed, and the window still never left the loading state.

    I also reproduced the hang after a full process kill + relaunch (identical result), and it is
    intermittent across launches on the same machine — sometimes the UI comes up, sometimes it does
    not, with no corresponding difference in the logged dependency states that I can find.

    What I think is still worth keeping from the addendum

    • The primary_runtime_install_failed → net::ERR_CONNECTION_CLOSED sequence is a real,
      reproducible way to wedge the UI      , and the failure is silent and terminal for that session.
      The workaround guidance (wait several minutes before killing; avoid Reset-AppxPackage) still
      applies to that specific case.
    • The general problem stands: the loading screen has no visibility into, or recovery from,
      a startup step that never completes       — whatever that step is. A "waiting on X" indicator plus
      a retry/timeout would have made this whole thread unnecessary.

    What would help

    If a maintainer can tell me which renderer-side condition gates the transition from the loading
    view to the main shell, I can capture the corresponding state on a hanging launch and on a
    working launch and diff them — I have both available on the same machine.

  9. lernicks0 commented on Oct 1, 2026

    @lernicks0
    lernicks0
    on Oct 1, 2026

    SOLVED on my machine — the blocker was incomplete Windows elevated-sandbox provisioning

    Replacing my earlier "correction" comment: I found the actual cause and a fix, and it matches this
    report's symptoms exactly (window stuck on the loading spinner forever, web app fine on the same
    machine and account, repair/reset/reinstall all useless).

    The fix

    codex doctor (from the bundled CLI) reported this on the affected machine:

    ⚠ sandbox   elevated Windows sandbox provisioning is incomplete or outdated
    approval policy          OnRequest
    filesystem sandbox       restricted
    network sandbox          enabled
    sandbox backend          elevated
    sandbox provisioning     incomplete
  → run codex sandbox setup --elevated --user <end-user> --codex-home <authoritative-home> from an elevated shell

    Running exactly that, from an elevated shell:

    codex sandbox setup --elevated --user <user> --codex-home "$env:USERPROFILE\.codex"
# -> Windows elevated sandbox setup completed for <user> at C:\Users\<user>\.codex

    …and then relaunching the desktop app was enough. The app now loads normally.

    Evidence

    codex doctor before → after:

    Before After
    sandbox check ⚠ sandbox — elevated Windows sandbox provisioning is incomplete or outdated ✓ sandbox — restricted fs + enabled network · approval OnRequest
    summary line 17 ok · 1 idle · 8 notes · 7 warn · 0 fail 19 ok · 1 idle · 7 notes · 5 warn · 0 fail

    Desktop app log before → after. These events were completely absent on every hanging launch and
    appear as soon as the app actually reaches the UI:

    mcp_app_sandbox.guest_attached            guestWebContentsId=5 origin=codex-sandbox://...
mcp_app_sandbox.sandbox_document_committed
client.performance.span                   (renderer-side UI activity — 0 occurrences while hanging)
Reasoning summary turn-start config resolved  conversationId=<redacted>
AppServerConnection response_routed       conversationId=<redacted>

    So the sandbox guest failing to attach lines up with the UI never leaving the loading view.

    Why the standard remedies don't help

    Repair / Reset / reinstall / Reset-AppxPackage / clearing caches / changing network all leave the
    codex-home sandbox provisioning state untouched — which is why they do nothing for this, and why
    resetting (which does wipe other state) can make things worse.

    Suggested diagnostic path for anyone hitting this

    The CLI ships alongside the desktop app and is not always on PATH; it lives under
    %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe.

    1. Run codex doctor.
    2. If it reports the sandbox provisioning warning above, run the command it suggests from an
      elevated shell      .
    3. Relaunch the desktop app.

    On my machine step 2 alone resolved it.

    Two other failure modes I found on the same machine (possibly worth guarding)

    1. Primary runtime install failure. On one launch the app decided its runtime bundle was missing
      (trigger=startup_missing) and attempted a ~1.3 GB install at startup:

      primary_runtime_install_started   trigger=startup_missing
primary_runtime_bundle_install_outcome  durationMs=50586
  errorMessage=net::ERR_CONNECTION_CLOSED
primary_runtime_install_failed    errorMessage=net::ERR_CONNECTION_CLOSED

      That launch hung on the spinner too. A later launch completed the same install (196 s) and
      subsequent launches skipped it. Note Reset-AppxPackage / Settings → Reset forces this state.

    2. Long blocking windows in general. Even the successful paths took 21–196 s
      (durable host WebSocket connect 21–85 s; runtime install up to 196 s) with nothing shown on the
      loading screen. A user cannot tell whether to wait or to kill the app.

    The UI still has no visibility into, or recovery from, a startup step that never completes — that is
    the underlying defect regardless of which step is at fault. Showing the current startup phase plus a
    retry/timeout would cover all of the above.

  10. Yam-W commented on Oct 1, 2026

    @Yam-W
    Yam-W
    on Oct 1, 2026
    Author

    Confirmed: directly reloading the main renderer target (app://-/index.html) via the Chrome DevTools Protocol restores the app on my system.
    After launching the app with --remote-debugging-port=9222, I identified the app://-/index.html target and sent a Page.reload command over its WebSocket debugger connection. The app then recovered fully, including the main conversation pane and existing conversations.
    This workaround is more effective on my system than only killing the backend codex.exe processes, which previously allowed the shell/sidebar to load but left the main content pane blank.

  11. lernicks0 commented on Oct 2, 2026

    @lernicks0
    lernicks0
    on Oct 2, 2026

    Actual root cause found (both of my earlier comments were wrong)

    I have to correct myself a second time. Neither the primary-runtime install nor "unknown cause" was
    it. The mechanism is:

    When the app's selected remote host is unreachable, the window stays blank forever — no error,
    no fallback, no way out from inside the app.

    What the evidence looked like

    The app was configured with a Codex-managed remote host, and it was the selected host:

    "codex-managed-remote-connections":[{
  "hostId":"remote-ssh-codex-managed:<uuid>",
  "displayName":"<host>",
  "source":"codex-managed",
  "hostname":"<host>",
  "sshPort":11451
}],
"selected-remote-host-id":"remote-ssh-codex-managed:<uuid>"

    The app repeatedly reported the connection as down:

    [electron-message-handler] remote_connections.manager_state_set
  hostId=remote-ssh-codex-managed:<uuid> nextError=null nextState=disconnected

    …while the window never left the loading state. On that machine the loading screen rendered
    essentially nothing — measured ~0.1 % non-background pixels, i.e. a plain white window with no
    marking at all.

    The remote host's hostname simply had no DNS record. The server itself was up and reachable on
    the raw IP (SSH port open), but the configured hostname resolved to nothing, so the SSH connection
    could never establish. Nothing in the UI said so.

    Confirming it

    After making the configured hostname resolve to the real server IP (a local hosts entry), nothing
    else was changed and the same launch produced:

    [electron-message-handler] remote_connections.manager_state_set ... nextState=connected   (×3)
[AppServerConnection] response_routed ... errorCode=null
[BundledPluginsMarketplace] plugin_marketplace_sync_completed
[electron-message-handler] chatgpt_pubsub_transport_opened rendererWebContentsId=1
[electron-message-handler] chatgpt_pubsub_topic_subscribed
mcp_extension_tool_discovery_failed : 0 occurrences   (was 1–3)

    …and the UI came up. So the entire failure was downstream of "selected remote host not reachable".

    Problems worth fixing here

    1. A dead remote host blanks the whole UI. It should show the connection state, an error, and a
      way to switch back to the local host.

    2. No user-visible indication at all. A blank white window with no spinner, no logo, no message.

    3. The selection cannot be cleared from outside the app. Setting
      selected-remote-host-id to null (with the app closed) does not stick — on next launch:

      [remote-connections/selection] persisted_selection_reconciled
  availableConnectionCount=1 persistedSelectedRemoteHostId=null

      The app reconciles the selection straight back to the only configured connection, so a user
      whose only remote host is broken is locked out of the UI with no recovery path.

    Separately: stale runtime paths break MCP startup

    Unrelated to the above, but also real and also capable of leaving the UI stuck. The cached runtime
    directory is named by a content hash, and persisted configs reference it by full path. When that
    hash changes, the stale paths are not rewritten:

    config.toml            ...\runtimes\cua_node\<OLD_HASH>\bin\node_repl.exe
                       ...\runtimes\cua_node\<OLD_HASH>\bin\node.exe
                       ...\runtimes\cua_node\<OLD_HASH>\bin\node_modules
plugins\...\unified-computer-use\<ver>\.mcp.json   (6 references to <OLD_HASH>)
chrome-native-hosts-v2.json                        (3 references, ×2 files)
       ↓  the <OLD_HASH> directory no longer exists; the new one is <NEW_HASH>
MCP startup failed: The system cannot find the path specified (os error 3)

    Updating those paths to the current hash removed the failures
    (mcp_extension_tool_discovery_failed: 3 → 0). Same class of fault applies to the CLI's own
    bin\<hash>\ directory, where an absolute path becomes invalid after the hash rotates.

    Summary of my corrections

    Comment Claim Status
    First addendum "primary runtime install failure is the root cause" Wrong as a general cause — it is one way to wedge the UI, not the cause
    Correction "all dependencies healthy, cause unknown" Wrong — I had not yet found the unreachable selected host
    This comment "unreachable selected remote host blanks the UI" Reproduced and confirmed

    Apologies for the noise on this thread. The common thread across all three — and the thing that
    actually needs fixing — is that the loading screen has no visibility into, and no recovery from,
    a startup step that never completes    , whatever that step happens to be.

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