[Windows 26.924] Every cold startup stalls on Loading; restarting only app-server restores UI

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

26.924.22138 (build 11645); MSIX 26.924.2738.0; bundled app-server 0.158.0-alpha.2.1

What subscription do you have?

Not included in this diagnostic report

What platform is your computer?

Windows 11, 10.0.26100, x64

What issue are you seeing?

After updating, normal startup repeatedly leaves the Desktop window on Loading indefinitely. The app-server handshake, configuration reads, authentication checks and project migration succeed, but the UI does not finish initialization. Ending only the initial codex.exe backend leaves Desktop running; its automatically restarted backend restores the UI in roughly 3–4 seconds, and existing conversations can send and receive messages. Normal Exit and relaunch reproduces the problem.

Latest reproduction, 2026-09-26 UTC:

15:25:06.487: initialize handshake succeeds (85 ms).
15:27:07.264: app_start outcome=failure reason=timeout (~121 seconds).
15:31:42.968: replacement backend starts after user ends initial backend.
15:31:43.053: replacement handshake succeeds (84 ms).
15:31:46.845: main renderer app routes mounted (~400 seconds after startup).

No permanent fix has been established. Please investigate the initial initialization/request-completion path while preserving existing user data.

What steps can reproduce the bug?

Normally exit Desktop using the system-tray Exit command.
Wait at least 15 seconds and launch via the registered Windows application entry.
Observe persistent Loading for more than two minutes.
With no task running, end only that initial codex.exe app-server process.
Desktop stays running, launches a replacement backend and loads successfully.
Existing conversations work, but another normal exit/relaunch reproduces the failure.

What is the expected behavior?

Normal startup should complete without manually terminating app-server. Initialization reads should have bounded failure/recovery, and the supported fix must preserve conversations, project/workspace registrations and .codex data.

Additional information

Verified checks:

Bundled and staged codex.exe are both 0.158.0-alpha.2.1 with identical SHA-256: 8F0554EDE25BBC5450921897C468B2E84635AA513C5017457997AF0954581F49.
One normal-exit capture found zero related Desktop/backend/helper processes immediately after exit and 15 seconds later.
Failed backend PID 30468 and recovered PID 13308 had the same Desktop parent PID 4140, executable path and complete command line. Arguments: -c features.code_mode_host=true app-server --analytics-default-enabled -c plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true
Doctor reported healthy databases, config loaded, successful app-server initialization, HTTP reachability and WebSocket HTTP 101. Optional MCP and thread-inventory warnings exist, but their relationship to Loading is unproven.
Renaming Chromium/GPU caches did not fix it. Persistent storage and .codex were not reset.
EPIPE also occurred during shutdown after successful recovery/chat, so it is not established as the startup cause.
Desktop build commit: 2e782921399a788a842b74ee1944a2e1e6e003a1.

Read-only bundle inspection (hypothesis, not confirmed root cause): codex-home awaits local execution-path/workspace-root readiness; its renderer request manager retains requests until response or cancellation, with no intrinsic timeout observed in the inspected sendRequest method. Successful local bridge responses use a chunked sender with loading/queue/acknowledgement state. Existing logs cannot distinguish handler wait, response delivery failure or renderer promise settlement failure. Please trace those boundaries and add safe recovery for idempotent reads without replaying submissions.

Diagnostic limitations: an early diagnostic attempt directly launched ChatGPT.exe and introduced a separate package-identity failure. Registered IApplicationActivationManager activation corrected that. The latest launch received --inspect=127.0.0.1:9230, but no inspector opened. Read-only chrome.dll inspection found Electron fuse v1, 9 states, 010011001: EnableNodeCliInspectArguments (index 3) is disabled. No runtime queue snapshots were collected, no fuse or installed file was modified, and port 9230 was confirmed absent afterward. Please provide a supported diagnostic route or fixed build.

Related reports (not proof of the same root cause): #44342 and #45371. This report adds a reproducible whole-startup stall on 26.924 and identical failed/replacement backend process evidence.

No raw chat history, authentication files or full configuration is included.

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

[Windows] Codex Desktop 26.924.1866.0 stuck on startup spinner until app-server codex.exe is terminated #48333
Windows: older chats fail with "list_turns is not supported yet"; still need to kill codex.exe on every launch (#48333) #48450
Windows desktop app stuck on loading screen after update — app_start bootstrap timeout after codex-home request (26.924.2738.0) #48463

Powered by Codex Action

Additional reproduction on Windows with the same MSIX package version.

Installed package: OpenAI.Codex 26.924.2738.0 x64
Stable Codex app launches to the gray startup screen with the spinner and does not progress.
Fully exiting/restarting the app did not help.
Rebooting Windows did not help.
Clearing/renaming the local Codex cache did not help.
Windows app Repair/Reset and uninstall/reinstall did not help.
approval_policy = "untrusted" is not present in ~/.codex/config.toml.
The Codex CLI is not installed / not on PATH on this machine, so codex doctor could not be run.
Installing and launching the current Beta desktop app on the same machine/account works normally.

This stable-vs-Beta contrast suggests the failure is specific to the current stable Windows desktop build/path rather than the machine, account, or project data in general.

No destructive changes were made to project directories.

I can reproduce the same startup hang on another Windows system.

Environment:

Windows build: 10.0.26200, x64
Desktop version: 26.924.22138 (build 11645)
MSIX package: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0
Bundled app-server: 0.158.0-alpha.2.1

The app stays on the loading screen after reboot. Resetting/reinstalling did not provide a lasting fix. Creating a fresh .codex profile allowed one successful launch, but the problem returned after reboot without restoring any previous data. Testing a mobile hotspot also did not help.

Workaround observed:
While the desktop window remained open and loading, I terminated the background codex process in Task Manager. The desktop automatically restarted its app-server, and the UI loaded approximately 2 seconds later. Sending a message then worked.

Log timeline on September 27, 2026 (UTC):

19:15:52.061: app_start outcome=failure reason=timeout
19:17:16.285: initial app-server connection closed after my manual termination
19:17:16.699: replacement app-server spawned
19:17:16.836: initialize handshake succeeded
19:17:18.256: main UI routes mounted

Authentication and the initial app-server connection succeeded before the hang. The process termination above was intentional, not a spontaneous crash.

Please investigate why initial startup stalls while an automatic backend restart allows the same desktop session to recover. I have startup and recovery logs available.

Additional confirmed reproduction on Windows 10, with network and TLS checks:

Environment

Windows 10 Home 22H2, build 19045, x64
Installed MSIX package: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0

Symptom
On a cold launch, the ChatGPT/Codex Windows desktop app remains on its loading spinner indefinitely.

Troubleshooting already performed

Windows app Reset and Repair
Complete uninstall and reinstall
Cleanup of LocalCache, LocalState, and TempState
Windows reboot
Verified WebView2, DNS resolution, TCP 443 connectivity to chatgpt.com and auth.openai.com, and TLS
Ruled out third-party Avast/McAfee antivirus or network filtering

The desktop process establishes external HTTPS connections, and ChatGPT works in a browser. The observed chatgpt.com TLS certificate issuer was Google Trust Services; the checks found no indication of TLS interception. These findings do not point to a basic DNS, HTTPS, or browser-service outage.

Workaround confirmed on this machine

Leave the desktop window open while it is stuck on the spinner.
Terminate only the codex.exe process whose command line contains app-server.
The desktop app automatically spawns a replacement app-server.
Within seconds, the UI finishes loading and ChatGPT is usable.

I successfully reproduced this recovery on my machine. The first app-server launch appears to be the failing path; the automatically restarted backend succeeds without closing the desktop window. Please investigate the cold-start initialization path and provide a permanent fix that preserves user data.

Additional reproduction on Windows 11 Pro 10.0.26200 x64, with the same desktop 26.924.22138 / build 11645, MSIX 26.924.2738.0, and bundled app-server 0.158.0-alpha.2.1.

On 2026-09-28 I recorded:

A failed launch: initialize handshake succeeded in 175 ms, then primary app_start timed out at about 121 seconds.
A separate controlled recovery: desktop PID 23328 stayed running while only its verified idle initial backend PID 3828 was ended with exit code 0. The app started replacement backend PID 10716.
06:26:17.712 UTC: intervention.
06:26:17.933 UTC: replacement handshake succeeded.
06:26:18.927 UTC: primary renderer routes mounted — 1.215 seconds after the intervention. I confirmed the UI opened.

No database or .sandbox folder was deleted for that recovery. All 14 checked databases across my original and alternate CODEX_HOME passed integrity_check, with zero foreign-key violations. Standalone project/thread reads and authenticated account API checks also succeeded.

This happens repeatedly in both homes, but not on every launch. The recovered run logged primary-mounted only; a separate later launch logged full app_start outcome=success with shell_visible and sidebar_ready. I am keeping those observations separate.

I have attached selected, redacted startup logs and a fuller report. This supports investigating initial connection/state delivery or renderer initialization, but I cannot yet identify the exact missing event or unresolved request. Please advise on supported diagnostics or a fixed build that preserves user data.

Codex-startup-issue-20260928.zip

useful,I open GPT desktop ！！！

Sharing a reproducible workaround from another Windows installation, plus the constraints used for an on-demand launch-and-recover shortcut.

Status: temporary workaround, not a permanent fix. The manual recovery below has worked repeatedly on my machine. I have now also tested the new launch-and-recover shortcut and confirmed that it works here. This does not establish a permanent fix or reliability across repeated future launches.

What is confirmed on this machine

Installed MSIX: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0.
Normal exit and startup still leave the desktop spinning. Rebooting and reinstalling did not resolve it.
Leaving the desktop window open and stopping only its direct codex.exe app-server child allows the desktop to automatically start a replacement backend and recover.
After recovery, an actual tool execution of Get-Location succeeded.
A separate sandbox setup problem is no longer blocking commands; the reported setup result is now errors=[]. That does not mean the startup spinner is fixed.

Manual recovery that worked

Use this only while the desktop is stuck at startup and no task is running. Run it in a separate PowerShell window, not from a Codex task. It intentionally interrupts that desktop's backend, so it must not be used on a working session with active tasks.

Keep the desktop window open. The following is the same process-selection/stop logic used successfully here, with messages translated to English:

& {
    $ErrorActionPreference = 'Stop'
    $all = @(Get-CimInstance Win32_Process)

    $desktop = @($all | Where-Object {
        $_.Name -eq 'ChatGPT.exe' -and
        $_.ExecutablePath -match '\\OpenAI\.Codex_[^\\]+\\app\\ChatGPT\.exe$' -and
        $_.CommandLine -notmatch '--type='
    })

    $backend = @($all | Where-Object {
        $_.Name -eq 'codex.exe' -and
        $_.ParentProcessId -in $desktop.ProcessId -and
        $_.CommandLine -match '(?:^|\s)app-server(?:\s|$)'
    })

    if ($backend.Count -ne 1) {
        $backend | Format-List ProcessId, ParentProcessId, CommandLine
        throw 'Could not uniquely identify the desktop backend. Nothing was stopped.'
    }

    Stop-Process -Id $backend[0].ProcessId
    'Stopped only that backend. Leave the desktop open and wait about 10 seconds.'
}

This is a manual snapshot-based command, not an atomic identity guarantee. Do not broaden it to terminate all codex.exe processes. Successful recovery here does not establish that it will work on every affected system.

On-demand shortcut approach — now tested successfully here

To avoid repeatedly entering the command, I had a separate “Codex Launch and Recover” entry prepared with stricter protections:

If the desktop is already running, activate its existing window and return without stopping any backend.
For a fresh launch, use normal Windows packaged activation of OpenAI.Codex_2p2nqsd0c76g0!App through IApplicationActivationManager, with no debug arguments. Do not directly execute the installed ChatGPT.exe.
Confirm the returned desktop PID was absent before activation, was created after activation began, and matches the registered executable path, Windows session and package family.
Select only its unique direct app-server child. Check its creation time, command line and approved executable path, and compare its file hash with the bundled backend. Hold a native process handle so a reused PID cannot redirect termination.
Wait at least 10 seconds after activation and at least 3 seconds after selecting the backend; require the desktop renderer to exist and recheck identities. Attempt one backend termination only. If identity changes, access is denied or matching is ambiguous, abort without widening the search or choosing another target.
Wait for a replacement backend under the same desktop and observe it for 5 seconds. Explicitly announce that recovery steps have ended and no further process stops will occur. This confirms backend replacement, not that the UI has finished loading.
Use a per-user/session mutex to suppress repeated double-clicks, show a visible “do not send tasks yet” progress window, and exit when finished. Keep waits bounded.

This shortcut does not detect the spinner: every eligible fresh launch through it attempts one recovery. Users must wait for the completion notice and a usable UI before submitting tasks.

No startup task, service, persistent watcher, debug injection, signed-package patch, execution-policy bypass or Beta installation was added. The original launch entry and user data were preserved. Removing the separate launcher folder and its shortcut removes the workaround.

The launcher passed 28 static/simulated checks before the real user test. The shortcut has now also worked in that test; this does not mean all timing/race conditions or future cold starts have been validated. Please continue investigating the first-start initialization/reconnection difference; these observations do not identify the exact missing event or unresolved request.

Independent reproduction on Windows x64, 2026-09-28. MSIX OpenAI.Codex 26.924.2738.0, Desktop client 26.924.22138, build 11645 (commit 2e782921399a788a842b74ee1944a2e1e6e003a1).

Confirmed from the running processes, a read-only copy of logs_2.sqlite + WAL, and the Desktop log:

18:32:32 UTC: initial app-server initialize handshake succeeded in 726 ms. Model-list HTTP requests returned 200 while the window remained on the startup spinner.
18:34:38: app_start outcome=failure reason=timeout, duration about 126,922 ms.
18:54:47: ended only the initial codex.exe app-server through Task Manager, leaving the main Desktop process running. Desktop automatically started a replacement backend; its handshake succeeded in 480 ms.
18:55:00: primary renderer app routes mounted. The home UI and project/thread lists became visible.

Important limitation: this was only a partial recovery. Opening two different existing local threads still left their content on a spinner. The Desktop log records successful thread/read responses (5 ms and 50 ms, errorCode=null), followed by thread_navigation timeouts at about 30 seconds and thread_hydration timeouts at about 120 seconds. It also records repeated plugin/list and plugin/installed renderer request timeouts; these do not establish the root cause.

A separate worker log reports failure of wsl.exe --status, but causality is unproven. No reset, reinstall, cache deletion, or configuration edit was performed. Existing drafts were preserved. Raw logs, conversation content, usernames, and workspace paths are omitted.

Please investigate both startup completion and the remaining thread hydration failure, and provide a supported fix that preserves existing conversations and project registrations. Related thread-loading report: #48216.

Same hang here: Windows 11 Pro 10.0.26200 x64, MSIX OpenAI.Codex_26.924.2738.0, build 11645, bundled app-server 0.158.0-alpha.2.1. Store uninstall/reinstall and a fresh .codex-global-state.json do not help.

One data point from the desktop log that may narrow it down:

The initial local connection never leaves connecting. After initialize_handshake_result outcome=success, the log shows app_server_connection.state_changed cause=post_initialize_connection_state currentConnectionId=1 currentState=connecting. Every following request (config/read, account/read, getAuthStatus, fs/readFile…) routes fine, but connection 1 never transitions to connected, and no remote_connections.connection_state_changed / manager_state_set for hostId=local is ever sent to the renderer. The window stays on the spinner until app_start outcome=failure reason=timeout.
Killing only codex.exe app-server: the replacement connection reaches connected about 70 ms after its handshake (manager_state_set hostId=local nextState=connected), and app routes mounted follows about 2 s later.
Reloading the renderer (DevTools / CDP Page.reload) without touching the app-server also unblocks the UI. So the initial connected transition is either never emitted for connection 1 or emitted before the renderer subscribes.

Stopgap for people who need the app daily: a scheduled task at logon runs this watcher. When a new main ChatGPT.exe starts and its desktop log still has no connection_state_changed after 12 s, it stops that process's codex.exe app-server child. The app respawns the child and loads normally. When startup is healthy, the watcher does nothing.

Watcher (PowerShell)

$logRoot  = Join-Path $env:LOCALAPPDATA 'Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs'
$graceSec = 12

function Test-InterfaceReady([int]$mainPid, [datetime]$since) {
    $log = Get-ChildItem $logRoot -Recurse -Filter "*-$mainPid-t0-*.log" -ErrorAction SilentlyContinue |
        Where-Object { $_.LastWriteTime -ge $since.AddMinutes(-1) } |
        Sort-Object LastWriteTime -Descending | Select-Object -First 1
    return [bool]($log -and (Select-String -Path $log.FullName -Pattern 'connection_state_changed' -Quiet))
}

function Repair-Launch($main) {
    $started = $main.CreationDate
    do {
        if (Test-InterfaceReady $main.ProcessId $started) { return }
        if (-not (Get-Process -Id $main.ProcessId -ErrorAction SilentlyContinue)) { return }
        Start-Sleep -Seconds 1
    } while (((Get-Date) - $started).TotalSeconds -lt $graceSec)
    if (Test-InterfaceReady $main.ProcessId $started) { return }
    Get-CimInstance Win32_Process -Filter "Name='codex.exe'" |
        Where-Object { $_.ParentProcessId -eq $main.ProcessId -and $_.CommandLine -match ' app-server' } |
        ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }
}

$known = @{}
while ($true) {
    $ids = @(Get-Process -Name ChatGPT -ErrorAction SilentlyContinue | ForEach-Object { $_.Id })
    $new = @($ids | Where-Object { -not $known.ContainsKey($_) })
    $known = @{}; foreach ($i in $ids) { $known[$i] = $true }
    if ($new.Count -gt 0) {
        $main = Get-CimInstance Win32_Process -Filter "Name='ChatGPT.exe'" |
            Where-Object { $new -contains $_.ProcessId -and $_.ExecutablePath -like '*\OpenAI.Codex_*' -and $_.CommandLine -notmatch '--type=' } |
            Select-Object -First 1
        if ($main) { Repair-Launch $main }
    }
    Start-Sleep -Seconds 2
}

Register it with a logon trigger running powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File <path>. Keep the script outside %LOCALAPPDATA% if you create it from another MSIX-packaged app: those writes are virtualized, and the scheduled task will not see the file.

Additional reproduction from another Windows user on the same current build.

Environment

Windows Desktop Codex MSIX: 26.924.2738.0
Bundled app-server observed: 0.158.0-alpha.2.1

Symptoms

On cold launch, Codex Desktop frequently remains indefinitely on the loading spinner.
If only the direct codex.exe ... app-server child of the Codex Desktop process is terminated while the window stays open and no task is running, Desktop automatically starts a replacement backend and the UI becomes usable within seconds.
The problem returns on later launches, so this is only a temporary recovery.

Troubleshooting already tried

Windows Repair
Reinstall
Normal relaunch/restart
No project repositories or .codex data were deleted because there are important local projects/worktrees.

Log observations

The app-server process starts.
The initialize/stdio handshake succeeds.
Authentication/project loading proceeds.
The Desktop UI can still stall afterward.
The logs repeatedly contain No owner repo found for remote task warnings around the affected sessions.

This makes the Desktop application effectively unusable for sustained project work because manual app-server termination is repeatedly required. The web app works, and the local project files/repositories themselves are intact.

Please prioritize a fix that preserves local projects, conversations, worktrees and .codex state.

Additional reproduction and frontend diagnostics from Windows on 2026-09-29. This adds an observed startup gate and a confirmed renderer-only recovery, without restarting the backend.

Environment

Windows x64; OS version reported by desktop logs: 10.0.26200.
Microsoft Store package: OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0.
Desktop log build: 11645; commit: 2e782921399a788a842b74ee1944a2e1e6e003a1.
Bundled backend: codex-cli 0.158.0-alpha.2.1, stdio app-server.
Launched using the registered Windows application identity.

Reproduction and impact

Repeated full app shutdown/relaunch leaves the primary window on a dark loading spinner. Closing/reopening just the window and creating a fresh app window also left the spinner. The desktop UI is unusable until recovery.

Observed frontend blocker

During temporary localhost renderer debugging, the startup gate (minified component Jui) had:

ChatGPT authentication ready, with a stored token present (token contents were not collected for this report).
Feature access allowed; onboarding context and workspace-root queries successful.
Gateway-auth readiness still "loading".
The local app-server version signal read by that gate was null.

Read-only inspection of the installed frontend showed that this gateway-auth readiness calculation returns loading immediately when the local app-server version is null. The version is set by handling codex-app-server-initialized. Meanwhile, desktop logs reported a successful backend initialize handshake and a connected backend.

This identifies the observed blocking state. A lost/late initialization notification or frontend state synchronization defect is a hypothesis, not a proven root cause; the exact delivery boundary was not established.

Recovery confirmed on this machine

A debugger-triggered Page.reload of the app frontend recovered the UI once. A subsequent normal full restart reproduced the spinner.
Later, with no debugging enabled, only the app's child ChatGPT.exe --type=renderer processes were stopped while the main desktop process and its codex.exe app-server stayed running.
The app's built-in renderer-crash recovery reloaded the interface. The home screen/sidebar became available, and the user confirmed recovery with a screenshot.
The desktop log recorded the following sanitized success evidence:

2026-09-29T02:36:18.079Z
name=app_start outcome=success reason=null
durationMs=11478.4
shell_visible=9806.6 home_visible=9806.6 sidebar_ready=11478.3

These durations are the startup span's measurements, not a separately measured time from process termination. The renderer termination was intentional diagnostic intervention, not a spontaneous crash. This is a workaround; permanent cold-start recovery is unverified.

Checks and unsuccessful remedies

Renamed disposable Chromium/code/GPU caches; no improvement.
Separate clean Chromium user-data directory; no improvement (not a full clean CODEX_HOME test).
Temporarily reset persisted interface preferences; no improvement; restored original preferences.
Microsoft Store package repair completed successfully; startup still spun. Store reported no newer update.
IPv4/IPv6 connectivity worked; authenticated startup APIs returned HTTP 200 and WebSocket upgrade returned 101.
WARP was disconnected; no WARP route or system proxy was found.
Sandbox service was running; a read-only readiness request to the bundled backend returned {"status":"ready"}.
No evidence connected the inspected MCP configuration or PostToolUse/Stop hooks to the startup gate.

Ctrl+R was not a recovery on this build: it targets the embedded browser page, and the app-window Reload menu item is disabled in the production build. This distinction matters when recommending reload.

Please investigate delivery/replay of codex-app-server-initialized and initialization of the local app-server version signal before gateway-auth readiness is evaluated. A supported frontend reload/retry or bounded startup error would also help users recover without resetting their data.

No installed binaries, sandbox policy, or network settings were changed. Temporary debugging was closed. Raw logs, authentication files, chat contents, project names, screenshots, and account identifiers are not attached to this public report.

Additional reproduction after the renderer/backend recovery attempts on the same Windows machine:

The repository/conversation UI eventually became visible again after recovery steps.
A previously pending request remained stuck in the small queued/pending state in the composer.
That pending request was discarded from the UI.
A new minimal test message was then submitted: "Responde solamente OK".
The minimal message also remained indefinitely in the same pending/loading state and did not proceed to a normal turn.

This is important because the failure persists even after:

the main repository/conversation view is visible again, and
the new input is trivial and unrelated to repository complexity.

Earlier logs from the same session showed successful local backend communication and thread setup, including a successful thread/start with errorCode=null, while frontend spans later failed with timeouts such as:

thread_navigation outcome=failure reason=timeout
thread_hydration outcome=failure reason=timeout
thread_history_page outcome=failure reason=timeout

Renderer-only recovery restored the shell but did not restore reliable submission of new turns. A subsequent attempt to restart the desktop child backend from a normal PowerShell session was blocked by Windows with Access Denied; no data-reset or destructive workaround was attempted.

Current practical state: Desktop can sometimes render an existing repository/conversation after recovery, but new messages may still remain indefinitely pending, including the minimal one-line test above.

No repository files, .codex data, auth files, or worktrees were deleted or reset during this reproduction.

Additional reproduction and read-only diagnostics on the newer Windows build 26.928, with a first-party MCP tool-discovery timeout observed during startup.

Environment

Windows x64, local Desktop execution.
Installed MSIX package: OpenAI.Codex_26.928.1915.0_x64__2p2nqsd0c76g0.
Desktop client version reported in backend request logs: 26.928.20755.
Local app-server: 0.159.0, stdio transport.
Bundled codex-app-tools plugin: 0.1.5.

User-reported reproduction

The app stops progressing on every startup. Keeping Desktop open and force-stopping the codex.exe process(es) whose command line contains app-server restores usability. This is a temporary recovery; no permanent fix has been verified.

The user's original process filter is broad and can also terminate VS Code/other app-server instances. Those instances were observed during inspection, so this report does not claim a controlled, Desktop-only termination experiment.

Observed timeline

Timestamps below are UTC on 2026-09-29 (the affected startup was September 30 at approximately 07:22 JST). These are selected log fields, with local paths and identifiers omitted.

22:22:22.307
[AppServerConnection] Current reported app-server version:
currentVersion=0.159.0 hostId=local
[AppServerConnection] initialize_handshake_result
durationMs=131 outcome=success transportKind=stdio

22:22:22.308
[AppServerConnection] app_server_connection.state_changed
cause=post_initialize_connection_state
currentState=connecting next=connected initialized=true hostId=local

22:22:40.876672
WARN codex_mcp::rmcp_client
MCP server startup failed server_name="codex_app"
error=timed out awaiting tools/list after 10s

22:22:40.925
[AppServerConnection] response_routed
method=mcpServerStatus/list durationMs=10364 errorCode=null

22:22:40.965
[electron-message-handler] mcp_extension_tool_discovery_failed
error="MCP startup failed: timed out awaiting tools/list after 10s"
hostId=local pluginId=codex-app-tools@openai-bundled server=codex_app

22:23:00.160
[AppServerConnection] app_server_connection.closed
code=4294967295 signal=null transport=stdio

22:23:00.202
[StdioConnection] stdio_transport_spawned
[AppServerConnection] Transport start success

22:23:00.594
[AppServerConnection] initialize_handshake_result
durationMs=392 outcome=success transportKind=stdio

22:23:00.775
[electron-message-handler] app_server_restart_recovery_done hostId=local

22:23:04.837
[electron-message-handler] Unknown dynamic tools response requestId
(request identifier omitted)

The backend exit is consistent with the user's reported force-stop workaround. The logs alone do not identify who terminated it; this is not presented as evidence of a spontaneous app-server crash. The close message includes the most recent MCP warning, which likewise does not establish that the warning caused the process exit.

Read-only implementation observations and causality limits

Inspection of the installed bundled code showed:

The codex_app MCP definition sets startup_timeout_sec: 10.
Its tools/list handler forwards the request through a native named pipe to the Desktop host.
The host obtains this catalogue by requesting dynamic tools from the primary renderer and waiting for its response.

This makes renderer startup/readiness or request/response settlement a plausible place to investigate. However, the observed MCP timeout could be a consequence of the UI startup stall rather than its cause. The later unknown dynamic-tools response is another observation, not proof that it belongs to the timed-out request.

Unlike the earlier comment reporting an initial connection that never reaches connected, this capture explicitly logs next=connected immediately after the first successful handshake. The renderer's app-server version signal and gateway-auth readiness were not measured here, so this does not confirm or contradict the frontend-state hypothesis in #48466 (comment).

Please investigate the initial renderer readiness/initialization notification and dynamic-tool catalogue request path on 26.928 / app-server 0.159.0, including whether a missed or late response prevents startup completion or safe retry.

Diagnostic inspection was read-only. No configuration, cache, database or installed binary was changed. No raw chat history, authentication files, full configuration, usernames, project paths, account identifiers or full log files are included.

Additional reproduction on Codex Desktop for Windows, observed 2026-09-30. This appears to match the cold-start/app-server recovery pattern in this issue.

Environment: Windows x64; Store package path shows OpenAI.Codex_26.928.1915.0_x64. Desktop main process is ChatGPT.exe. The local backend is codex.exe with the app-server argument.

Symptom: normal launch/relaunch can remain indefinitely on the Codex logo/loading screen. Logs nevertheless show successful app-server initialization/handshake, Codex CLI initialized, connected durable/WebSocket state, successful ChatGPT authentication, renderer load/ready-to-show, React root render request, and plugin/MCP initialization.

Troubleshooting that did not provide a durable fix: isolating Chromium Cache, Code Cache, GPUCache, Dawn caches, Session Storage; Ctrl+R/Ctrl+Shift+R; and isolating a malformed global-state JSON. Project data, authentication data, SQLite history, and config.toml were not deleted.

Strong A/B result: while Desktop remains on the logo, terminating only the local codex.exe process whose command line contains app-server causes Desktop to respawn/reconnect its backend and the logo disappears; the normal Codex UI becomes usable without restarting Desktop. A separate codex.exe exec-server process was deliberately left untouched. This recovery has been reproduced multiple times; subsequent cold starts can reproduce the logo stall and the same app-server-only restart restores the UI again.

Two initialization errors were also observed: fs/readFile requires an environmentId and /tbo?limit=25 returning HTTP 404. Their causal relationship is unknown because initialization continues afterward.

This suggests the initial app-server instance, or propagation of its readiness to the renderer, can stall even though logs report the backend as initialized/connected. Please investigate the initial startup/reconnection path and consider bounded automatic recovery that safely restarts/reconnects the local app-server while preserving conversations, project registrations, and remote exec-server processes.

Additional reproduction with a newer Windows desktop build, observed 2026-09-30. The user confirmed that the app became usable after the targeted recovery below.

Environment:

Windows 10, OS build 10.0.19045, x64.
Installed MSIX: OpenAI.Codex 26.928.2636.0.
Desktop log buildNumber: 12404; buildCommitSha: 2f11c102c54607d56bfc3716658fb262312c9233.
Desktop child backend executable reports codex-cli 0.159.2.

Reproduction: fully exit the app and launch through its registered Windows application entry. The window exists and backend requests run, but the main UI remains on loading. This recurred after an earlier successful recovery on the same day.

Selected diagnostic fields, UTC:

13:07:14.033: host startup critical-path phases completed.
13:09:46.513: app_start outcome=failure reason=timeout; durationMs=153260.1. renderer_ready and settings_ready had already been recorded.
During recovery, only the verified codex.exe app-server child of the running ChatGPT.exe was terminated. The app automatically created a replacement child; Desktop itself and the separate CLI/managed daemon were not stopped.
13:14:17.331: replacement connection initialized and transitioned to connected.
13:14:18.609: websocket_reconnect_recovery_done, refreshRecentConversationsFailed=false.
13:14:18.968: primary renderer app routes mounted after 425621ms.
13:14:18.974: Handled ready message.
The user then confirmed that the app opened successfully.

No history, profile, authentication, caches or configuration were reset for this recovery. No diagnostic port or binary patch was needed. This is a temporary workaround, not evidence of a permanent fix. It was performed while the affected conversation had no running turn; it should not be interpreted as a recommendation to terminate arbitrary codex processes during work.

Concurrent warnings included fs/readFile requires an environmentId and a codex_app MCP tools/list timeout. Their causal relationship is unproven. Please investigate the initial startup/readiness propagation and bounded recovery path. The backend is able to answer requests before the main UI finishes loading.

A separate pre-dispatch send-button stall was also observed in this installation; details are added to #45174. A common root cause has not been established. Only sanitized diagnostic fields are included here, not private prompts or full logs.

Reproduced on September 30, 2026 with Windows 10 Pro 10.0.19045, desktop package 26.928.2636.0, app version 26.928.21956, and bundled CLI 0.159.2.

Launching through the registered Windows app entry leaves the main window stuck on Loading despite successful backend initialization. Restarting only the desktop's child codex.exe app-server process, without closing the desktop window, restored the UI.

Relevant timeline, UTC:

12:42:45.274  Initial stdio handshake succeeds in 155 ms; UI remains loading.
12:44:03      Terminated only the desktop's child app-server process.
12:44:03.673  Replacement stdio handshake succeeds in 226 ms.
12:44:10.997  Main-window app_start reports outcome=success.
12:44:12.580  Main renderer reports app routes mounted.

The UI recovered approximately 8-9 seconds after the targeted backend restart, and I confirmed it was usable.

Additional checks:

Four local conversation/state databases passed SQLite quick_check.
Stale Node runtime paths and obsolete browser native-host registrations caused a separate missing required path nodePath error. Repairing those made the native-host connection succeed, but normal desktop startup still stalled.
Temporarily disabling the codex-app-tools plugin in user configuration did not clear the stall. It was subsequently re-enabled. This was a configuration-level test, not proof that all internal app-tools dependencies were disabled.
No conversation history, authentication data, or persistent app storage was reset.

This supports the reported startup/reconnection behavior on a newer build; it does not establish the underlying cause.

Additional reproduction on Windows, observed September 30, 2026. Installed MSIX package verified locally: OpenAI.Codex 26.928.2636.0.

The desktop repeatedly stays on the OpenAI logo/loading screen. The user reports that Repair, Reset and uninstall/reinstall did not resolve it. Updating today also did not prevent the startup hang.

The user confirmed three successful temporary recoveries by ending only the codex.exe app-server process while leaving the desktop window open, including after the update. Normal startup can still reproduce the hang.

Recovery remains incomplete:

Settings > Plugins stays at "Loading plugins...".
Work through an iPhone remote session has sometimes remained possible while the Windows UI was frozen.
Computer/browser access is intermittent. An earlier computer-control attempt returned: "Computer Use native pipe is unavailable: failed to connect native pipe: El sistema no puede encontrar el archivo especificado. (os error 2)". In the latest session, the computer/browser control tools are not exposed, so the earlier pipe error cannot currently be retested.
The user also reports that the microphone/dictation button has repeatedly been greyed out and unavailable on Windows only, not on the iPhone. This symptom is user-reported; a shared cause with the startup issue has not been established.

Enabling js_repl in configuration and restarting did not restore the missing computer/browser tools. We are not treating that setting as a fix for startup.

This partially resembles #43460 as well, but a common root cause is unproven. Please advise on supported diagnostics or a permanent fix that preserves existing conversations and configuration. This report contains no private logs, client data, account identifiers or private attachments.

Additional Windows desktop reproduction, investigated on September 30, 2026 (America/Bogota, UTC-5).

User-observed behavior over the last 2-3 days:

Opening the desktop application often leaves it on the loading screen indefinitely.
Ending a codex.exe process in Task Manager sometimes allows the UI to open.
Some recovered launches still cannot submit chat messages, requiring termination of the entire ChatGPT/Codex application and another launch.
These are the user's observations; this investigation did not deliberately terminate the active backend or reproduce a new cold launch while a task was running.

Environment verified locally:

Windows 11 Pro, version 10.0.26200, x64.
MSIX package: OpenAI.Codex 26.928.3736.0.
Desktop updater reports installedVersion 26.928.31416, build 12553, prod channel, up_to_date. MSIX package and internal application version are recorded separately.
Actual desktop backend executable reports codex-cli 0.159.2.

Selected observations (all UTC timestamps below):

Four desktop startup sequences between 01:50 and 01:59 on October 1 had successful local app-server initialization handshakes (167, 256, 291 and 237 ms). This alone does not prove the UI was usable.
The 01:50:18.243 successful local handshake was followed at 01:55:24.174 by name=app_start outcome=failure reason=timeout. Wall duration was 306425 ms, with 184387 ms backgrounded (approximately 122 seconds outside the background interval). The recorded readiness marks stopped at settings_ready; shell_visible, home_visible and sidebar_ready were absent. This is direct local evidence of startup failure despite a healthy handshake.
Other nearby launches recorded app_start outcome=success in approximately 5.5-6.1 seconds. They also logged the connected-plus-WARN-error state below, so that warning is not sufficient by itself to explain the hang.
A local backend restart at 01:57:20 was followed by another successful handshake in 166 ms; the logs do not establish whether the trigger was manual Task Manager termination.
Several launches record the bundled codex_app tool discovery timeout: "MCP startup failed: timed out awaiting tools/list after 10s".
At 01:56:02.318, after successful initialization, local host state was connected but error.code was connection-failed. Its error.message was a WARN-level record: "ignoring invalid experimental feature enablement keys: apps_mcp_path_override".
Similar connected-plus-connection-failed states occurred at 01:58:34 and 01:59:24. This feature key is absent from the user's config.toml. Read-only inspection of the installed application bundle found the key in the desktop's feature override list. Its causal relationship to the loading hang remains unproven.
Windows Application Hang event 1002 at 2026-10-01 01:58:48.558 UTC recorded ChatGPT.exe as unresponsive. A fresh desktop process started shortly afterward.
The bundled doctor reports healthy state databases, loaded configuration, configured authentication, successful desktop app-server initialization, HTTP reachability and WebSocket HTTP 101. It also reports optional MCP and historical thread-inventory warnings.

Important confounder / contributing condition:
Windows Resource-Exhaustion-Detector event 2004 recorded low virtual memory repeatedly on September 30 (UTC-5), including 20:14, 20:21, 20:33 and 20:41. At 10:50:32.789 local time, event 2004 was followed approximately 0.26 seconds later by a codex.exe Application Error 1000, exception 0xc0000409. This supports investigating resource exhaustion separately; it does not establish why every initial launch hangs.

A read-only process snapshot around 21:04 local time showed 107 processes in the local app-server family, including the backend and diagnostic shells: 21 node.exe, 18 cmd.exe, 12 python.exe, 6 node_repl.exe, 6 uv.exe, 6 uvx.exe, 3 markitdown-mcp.exe, 3 blender-mcp.exe and other helpers. Family private committed memory was approximately 4.92 GiB. System commitment was approximately 49.68 GiB of a 54.51 GiB limit (91%). Multiple helper instances are verified, but this single snapshot does not prove an unbounded leak. Another codex.exe was an exec-server, not a duplicate app-server; multiple codex.exe names alone do not identify an orphan process.

The machine's WSL memory cap had already been reduced to 6 GB earlier that day. Resource-exhaustion events continued afterward. Several unused STDIO MCP servers had also already been disabled in config; the startup issue persists according to the user.

Requested investigation:
Please investigate initial desktop startup readiness and recovery after local backend replacement, including pending request completion, correct distinction between WARN stderr and connection failure, and bounded tool-discovery failure. Please also investigate per-thread STDIO helper lifecycle under memory pressure, without treating the process snapshot as proof of leakage. A supported fix should preserve conversations, projects and authentication. Restart recovery must restore both UI loading and actual composer submissions.

Related reports: #48466 (initial launch hangs / backend restart recovers), #49687 (26.928 stable startup hang), #38614 (Windows helper process accumulation), #30378 (apps_mcp_path_override warning).

No raw conversations, full configuration, tokens, account identifiers, client names or private filesystem paths are included. No installed application files, settings, databases or security exclusions were changed in this investigation. A lasting fix and two successful sends from an affected existing desktop chat have not yet been verified.

Additional reproduction on MSIX 26.928.2636.0, captured on 2026-10-01. This is a failed native cold start followed by a successful manual relaunch using the same signed-in profile, not a claim of a permanent fix.

Environment verified locally:

Windows 11 Home, 10.0.26300, x64.
The desktop's actual child backend reports codex-cli 0.159.2.
TUN-based networking enabled; the system HTTP proxy switch disabled. This is not a no-VPN control, and the network stack has not been ruled out.

Failed cold start

The app was exited normally. An independent monitor confirmed that the desktop and its tracked backend children had exited, then launched it through the registered Windows application entry. The window remained on the startup logo/loading screen.

Selected log fields, all UTC, normalized to remove identifying fields:

2026-10-01 02:16:35.554  initialize_handshake_result outcome=success transportKind=stdio durationMs=156
2026-10-01 02:16:36.830  React root render requested; primary window
2026-10-01 02:16:38.665  primary account lookup: authenticatedAccountPresent=true result=succeeded
2026-10-01 02:16:45.099  initialize_handshake_result outcome=success transportKind=websocket durationMs=301
2026-10-01 02:16:45.099  hostId=durable next=connected
2026-10-01 02:23:04.966  local connection disconnected during the subsequent normal exit

The independent acceptance check reached its 90-second limit without primary GUI readiness. No primary app_start outcome=success / ready completion was observed before that later exit, approximately 6.5 minutes after launch. The 90-second limit is the test's limit, not an app-emitted timeout error. Local initialization, authenticated account lookup and durable WebSocket initialization had all succeeded while the GUI remained unusable.

Subsequent manual relaunch

A new desktop process started at 02:23:08.051 UTC. Earlier read-only inspection captured:

2026-10-01 02:23:10.147  initialize_handshake_result outcome=success transportKind=stdio durationMs=125
2026-10-01 02:23:19.813  primary account lookup: authenticatedAccountPresent=true result=succeeded
2026-10-01 02:23:26.367  primary app_start outcome=success; shell_visible present; durationMs=16326.3
2026-10-01 02:23:26.519  initialize_handshake_result outcome=success transportKind=websocket durationMs=251
2026-10-01 02:23:27.247  renderer ready message handled

The primary GUI was ready about 18.3 seconds after process creation. The plugin marketplace's public home page and the ChatGPT/Work project list were then visually confirmed usable. Phone Remote initially remained unavailable and subsequently recovered; a phone-network contribution is possible but unverified, so that is not being treated as evidence of the desktop startup cause.

Controls and limitations

No authentication/global-state clearing, cache reset, installed-binary modification, or targeted backend/renderer termination was used in this comparison.
The auth file hash was unchanged across the measured failed startup; global-state JSON remained valid.
A previous, non-official, version-pinned workaround was explicitly stopped before the failed run and did not match this newer package during the manual relaunch. It has now been completely removed.
The successful-launch fields above were captured before log rotation removed that startup segment from the current rotating files. These are saved diagnostic fields, not an attached complete raw log.
The two different launch outcomes do not establish that the launch method caused the difference, nor do they establish two consecutive successful cold starts.

Please investigate the primary renderer's startup readiness/pending-request completion after successful local and durable initialization. A supported diagnostic that identifies the unresolved startup dependency would be useful. Recovery should preserve authentication and project registrations, and validation should cover the secondary pages rather than treating the backend handshake or outer window alone as success.

Only selected, sanitized diagnostic fields are included here. No raw conversations, credentials, full configuration, private paths or device/account identifiers are attached.

Additional reproduction on newer Windows Store packages: 26.928.2636.0 and 26.928.3736.0, observed September 30–October 1, 2026.

With an existing profile containing local and SSH projects:

Close and launch the desktop app.
It remains on a blank/loading screen; projects and conversations do not appear, although the process stays alive.
Updating to 26.928.3736.0 and launching again reproduces the problem.

Restarting only the desktop child app-server restored the interface on multiple occasions. A separate recovery used registered package activation with a loopback CDP endpoint followed by main-renderer reload, which also restored the UI. No profile, history, authentication or configuration reset was required; standalone CLI was left unchanged.

Expected: normal startup completes without manual process intervention. This confirms persistence of the same observed symptom and workaround on 26.928; it does not establish an identical root cause. Exact Windows build was not collected. A successful UI load did not always restore message sending, which is being reported separately.

No raw logs/screenshots attached. Prompts, project paths, host addresses, thread identifiers, and runtime state are omitted.

Navigation Menu

Repository navigation

[Windows 26.924] Every cold startup stalls on Loading; restarting only app-server restores UI #48466

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

What is confirmed on this machine

Manual recovery that worked

On-demand shortcut approach — now tested successfully here

Environment

Reproduction and impact

Observed frontend blocker

Recovery confirmed on this machine

Checks and unsuccessful remedies

Environment

User-reported reproduction

Observed timeline

Read-only implementation observations and causality limits

Failed cold start

Subsequent manual relaunch

Controls and limitations

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows 26.924] Every cold startup stalls on Loading; restarting only app-server restores UI #48466

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 26, 2026

rfv69165 commented on Sep 26, 2026

altair-procyon commented on Sep 27, 2026

az12sx45 commented on Sep 28, 2026

Hayatttt commented on Sep 28, 2026

shiningflashZZY commented on Sep 28, 2026

jiangzengyuang-jisoo commented on Sep 28, 2026

What is confirmed on this machine

Manual recovery that worked

On-demand shortcut approach — now tested successfully here

emrebirinci-ui commented on Sep 28, 2026

TomassonJW commented on Sep 28, 2026

diegoestesi-byte commented on Sep 29, 2026

priyadarshana commented on Sep 29, 2026

Environment

Reproduction and impact

Observed frontend blocker

Recovery confirmed on this machine

Checks and unsuccessful remedies

diegoestesi-byte commented on Sep 29, 2026

Maguro-Tsukiji commented on Sep 29, 2026

Environment

User-reported reproduction

Observed timeline

Read-only implementation observations and causality limits

henryyeh0902 commented on Sep 30, 2026

mower07 commented on Sep 30, 2026

rustyorb commented on Sep 30, 2026

cesargomezencinas-code commented on Sep 30, 2026

monjecsv commented on Oct 1, 2026

EvaZenith commented on Oct 1, 2026

Failed cold start

Subsequent manual relaunch

Controls and limitations

mower07 commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions