Windows ARM64 (Snapdragon X Elite): app hangs on splash / freezes at sign-in — no crash, no error in logs — on both 26.810.7004.0 and 26.803.10989.0

Summary

On a Surface Pro 11 (Snapdragon X Elite, Windows 11 ARM64), the unified ChatGPT/Codex desktop app starts, spawns its processes, connects to the app-server successfully, logs window ready-to-show, requests the React root render — and then stops. No error is written to the log. The window either never appears, or appears and sits on the OpenAI logo splash indefinitely, eventually showing "(Not Responding)".

This is not the known 0xC06D007F serialport/N-API crash (#33381 / #33415). The process does not die at ~10–16 s — it stays alive for minutes while consuming CPU and steadily growing memory.

The Codex CLI (@openai/codex 0.147.0) works perfectly on the same machine, same account, same network. chatgpt.com in the browser also works fine. Only the desktop app is affected.

Environment

Symptoms

1. App launches. Three ChatGPT.exe processes spawn.
2. Window either never appears, or appears showing the dark OpenAI logo splash.
3. Splash never progresses. After a few minutes the title bar shows "ChatGPT (Not Responding)".
4. Processes remain alive — observed 237 seconds with no exit — while memory climbs.
5. Memory growth is continuous: one ChatGPT process was observed at 2646 MB. The app gets progressively slower the longer it runs.
6. Before this started, the app caused system-wide lag and stuttering mouse movement — consistent with #38554 and #38659.

One partial breakthrough

Renaming %USERPROFILE%\.codex\auth.json aside allowed the app to get past the splash screen once and display the "Sign in to ChatGPT" screen. However, clicking "Continue to sign in" did not open a browser window, and the app then froze and closed unexpectedly. This is reproducible.

This suggests the hang is at or immediately after the auth/sign-in step, not at window creation.

Log evidence

Log path: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<yyyy>\<mm>\<dd>\

The log shows a clean startup with no errors, then simply ends:

info Launching app ... buildFlavor=prod packaged=true platform=win32
info [AppServerConnection] Starting app-server connection hostId=local transport=stdio
info [StdioConnection] stdio_transport_spawned ... codex.exe pid=9304
info [AppServerConnection] Transport start success connectionId=1
info [IpcRouter] I am the router
warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed
info [window-manager] window main frame finished load startupElapsedMs=1006 webContentsId=1 windowId=1
info [window-manager] window ready-to-show startupElapsedMs=1112 webContentsId=1 windowId=1
info [electron-message-handler] [statsig-refresh-diagnostics] React root render requested
    rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true
    rendererWindowId=1 rendererWindowVisible=true windowType=electron
info [AppServerConnection] Current reported app-server version: currentVersion=0.148.0-alpha.9
info [AppServerConnection] initialize_handshake_result durationMs=16725 outcome=success transportKind=stdio
info [AppServerConnection] Codex CLI initialized
info [AppServerConnection] app_server_connection.state_changed ... next=connected
info [electron-fetch-handler] codex-home request hostId=local
info [AppServerConnection] response_routed ... method=remoteControl/status/read
info [AppServerConnection] response_routed ... method=fs/readFile
info [electron-fetch-handler] codex-home request hostId=local
<log ends here — no further entries, no error, no exit record>

Two things worth noting:

• initialize_handshake_result durationMs=16725 — the app-server handshake takes 16.7 seconds.
• There is a ~25 second gap between Launching app and the next log line.

Both suggest something is blocking for a long time before the UI stage is even reached.

What was tried (all unsuccessful)

• Full uninstall (Remove-AppxPackage) + verification that no OpenAI.Codex package or leftover %APPDATA% / %LOCALAPPDATA% data remained, followed by a clean reinstall from the official CDN MSIX. No change.
• Reinstalling the current build 26.810.7004.0. No change.
• Rolling back to 26.803.10989.0 (published 11 Aug 2026, before the 26.810 line). Same behaviour — this rules out the 26.810 update as the cause.
• Renaming auth.json aside — got to the sign-in screen once, then froze on "Continue to sign in" (see above).
• Launching ChatGPT.exe directly with --disable-gpu --disable-gpu-compositing --disable-software-rasterizer. The processes spawned and stayed alive for 4 minutes but no window was ever created and no log file was written — presumably because launching the packaged EXE directly loses package identity. So GPU acceleration could not be conclusively tested this way. Note: Hardware-accelerated GPU scheduling is not available on this device (Adreno GPU does not expose it), so that toggle could not be tested either.
• System restart between attempts.
• No VPN or proxy in use.

What works on the same machine

• Codex CLI (npm i -g @openai/codex, codex-cli 0.147.0, native arm64 Node v24.16.0) — works perfectly.
• chatgpt.com in the browser — works perfectly, same account, same network.

Expected vs actual

Expected: the app finishes rendering after React root render requested and shows the UI.

Actual: rendering never completes. The main thread stops responding, memory grows without bound, and the app either hangs indefinitely on the splash or freezes and exits at the sign-in step.

Possibly related

• #33381 / #33415 — ARM64 crash, but that is a hard 0xC06D007F crash at ~10–16 s. This is different: no crash, process survives.
• #34277 — silent exit after a clean reset, distinct from the serialport exception.
• #33573 — Windows ARM64 app exits after loading main screen; also reports "Codex CLI works with the same account".
• #38554 / #38659 — system-wide stutter and mouse lag on 26.810 (reported on x64, but on the same OS build 26200.9168).

Happy to provide

Full log files, Crashpad reports (if any are being generated), Event Viewer entries, or output from any diagnostic command — just say what would help.

Start with the packaged Windows ARM64 startup logs and the flow around the app-server handshake, React root render request, and auth.json. Compare builds 26.810.7004.0 and 26.803.10989.0, including the sign-in and clean-install observations. Done means the app renders and completes sign-in without hanging, unbounded memory growth, or a not-responding window.