Windows app won't open after update, background process exists but no GUI window

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

• #24404

Powered by Codex Action

Same symptoms here, confirming this is not machine-specific.

Environment

• Windows 11 Pro, OS build 26200.8524
• Codex (Microsoft Store), version 26.609.3341.0

Behavior
Launching the app spawns the full Electron process tree — main + gpu-process + crashpad-handler + two utilities (network.mojom.NetworkService, storage.mojom.StorageService) — which all live for ~2.8–3.3s and then exit together. A renderer process is never created, so no window ever appears. The Rust CLI works fine.

Crucially this is a clean exit, not a crash: no WER report, no Crashpad dump, no Application/AppHost error in Event Viewer. The desktop log just stops at:

info Launching app ... packaged=true platform=win32
info Appshot hotkey inactive configured=true enabled=true platform=win32

i.e. the main process quits before it ever builds the window/renderer.

Already tried (all ineffective):

• Cleared the web profile cache
• Reset-AppxPackage (full reset to fresh-install state) — still exits at +3.3s with no renderer
• Reinstall / restart

Extra data point that may help isolate it: on this machine a Windows cumulative update (KB5094126, build 26200.8655) had separately made the bundled node.exe backend fail-fast with c0000409. Removing that KB eliminated the c0000409 crash entirely — but the GUI still won't open, with the clean-exit behavior above, on a known-good build (26200.8524) without KB5094126. So the "no window" problem is independent of the node crash and reproduces without that KB.

Happy to provide logs.

Adding another repro on the current Microsoft Store/MSIX build. This appears to be the same symptom, but on a newer package version and on an ASCII-only Windows user profile path.

Environment

• OS: Windows 11 Pro x64
• Version: 10.0.26200
• Build: 26200
• Codex Desktop/MSIX:
• OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Installed from Microsoft Store / MSIX
• Codex CLI:
• codex-cli 3.2.0
• Windows user profile path: ASCII-only (C:\Users\<redacted>) — no CJK/non-ASCII characters in the profile directory.

Reproduction

1. Launch Codex Desktop from Start Menu / AppUserModelId:

``powershell
Start-Process "shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App"
``

1. Wait 20 seconds.
2. Check Codex processes and Win32 top-level windows.

Actual behavior

The app starts a Codex process tree, but no GUI window is created.

Observed immediately after launch:

process_count=8 window_count=0

Id     MainWindowHandle  Responding
18316  0                 True
22140  0                 True
27056  0                 True
34976  0                 True
42172  0                 True
42728  0                 True
44304  0                 True
45260  0                 True

A direct Win32 enumeration over all Codex.exe PIDs also finds no top-level windows:

codex_pids=[18316, 20060, 22140, 27056, 34976, 42172, 42728, 42792, 44304, 45260]
top_level_window_count=0

So this is not just an off-screen or hidden main window: there is no top-level BrowserWindow / Win32 window associated with the Codex processes.

codex app also exits after printing the desktop handoff message, but the desktop GUI never appears.

Expected behavior

Codex Desktop should create and show the main GUI window.

What still works

The CLI is healthy and usable:

codex-cli 3.2.0

codex doctor --summary reports the local install/auth/state/connectivity as healthy overall:

Codex Doctor v3.2.0 · windows-x86_64
12 ok · 1 idle · 3 notes · 1 warn · 0 fail degraded

Environment
  ✓ runtime
  ✓ install
  ✓ search
  ✓ terminal
  ✓ state        databases healthy

Configuration
  ✓ config       loaded
  ✓ auth         auth is configured
  ⚠ mcp          MCP configuration has optional issues
  ✓ sandbox

Connectivity
  ✓ websocket    connected (HTTP 101 Switching Protocols)
  ✓ reachability active provider endpoints are reachable over HTTP

Notes

• Killing the full Codex.exe process tree and relaunching does not restore the GUI.
• Reinstalling the MSIX package restored the same package version (26.616.4196.0) and did not change the behavior.
• This does not appear to be the CJK/non-ASCII Windows username variant because the affected profile path is ASCII-only.
• The CLI and local Codex state DBs remain usable; the failure seems limited to the Windows Desktop GUI process/window creation path.

Follow-up: I also tested after explicitly disabling WSL mode in config.toml and switching the integrated terminal back to PowerShell.

Changed settings:

[desktop]
integratedTerminalShell = "powershell"
runCodexInWindowsSubsystemForLinux = false

After killing all Codex.exe processes and relaunching the MSIX app, the behavior is unchanged:

5s: process_count=9 window_count=0
10s: process_count=9 window_count=0
15s: process_count=11 window_count=0
...
60s: process_count=11 window_count=0
No GUI window after 60s

Final process snapshot:

Id     MainWindowHandle  Responding
4328   0                 True
6468   0                 True
10948  0                 True
11772  0                 True
17260  0                 True
25960  0                 True
29064  0                 True
30804  0                 True
36128  0                 True
42748  0                 True
46116  0                 True

The latest logs no longer show the previous repeated WSL spawning pattern; app/plugin/list calls return, but the desktop app still creates no visible/top-level window.

I hit the same issue on Windows after a clean/first install of the Codex desktop app: opening Codex Desktop created several background Codex.exe processes, but no UI
ever appeared.

I asked Codex-CLI to find the issue for me and it got it running. Below is what Codex-CLI did to fix the issue for me, I asked it write down the steps so this is a copy/paste of that:

  What fixed it for me was repairing the local `cua_node` runtime that Codex was leaving in a `.staging-*` folder.

  In PowerShell:

  powershell
  # 1. Stop the stuck Codex Desktop processes
  Get-Process -Name Codex -ErrorAction SilentlyContinue |
    Where-Object { $_.Path -like '*\WindowsApps\OpenAI.Codex_*\app\Codex.exe' } |
    Stop-Process -Force

  # 2. Check the Codex runtime folder
  $base = Join-Path $env:LOCALAPPDATA 'OpenAI\Codex\runtimes\cua_node'
  Get-ChildItem -Force $base

  In my case, that folder only contained something like:

  .staging-1b23c930bdf84ed6-tbG5E1

  and no finalized runtime directory.

  I verified the staged Node runtime worked:

  & "$base\.staging-1b23c930bdf84ed6-tbG5E1\bin\node.exe" --version

  It printed:

  v24.14.0

  Then I manually renamed the staging directory to the hash part of the name:

  Rename-Item `
    -LiteralPath "$base\.staging-1b23c930bdf84ed6-tbG5E1" `
    -NewName "1b23c930bdf84ed6"

  After launching Codex Desktop again, the UI finally appeared.

  For reference, the useful log file was under:

  %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs

  Before the fix, the app log stopped very early after startup. After the fix, it got past app-server initialization and
  showed the main window.

  One caveat: your staging folder will likely have a different suffix. The finalized directory name should be the hash
  between .staging- and the final random suffix. For example:

  .staging-1b23c930bdf84ed6-tbG5E1
           ^^^^^^^^^^^^^^^^
           final folder name

Confirmed another recovery path for this exact no-GUI/no-renderer symptom on the current Microsoft Store build.

Environment and failure signature

• Package: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
• Package status, AppX registration, deployment, and activation were healthy.
• The Electron main, Crashpad, GPU, network utility, and storage utility processes remained alive.
• The bundled codex.exe app-server initialized and reached connected.
• No --type=renderer process was created and no top-level window existed.
• No current WER/Application Error, Crashpad dump, Sentry event, or native-addon error was present.

Restart, Store update, AppX re-registration, GPU-disabled launch, and rotating GPU/Dawn/Code caches did not help.

The cua_node runtime was already finalized and healthy (v24.14.0), with no .staging-* directory, so the July 7 staging-directory workaround above did not apply.

Root cause indicator

The shared Codex log database was unusually large:

~/.codex/logs_2.sqlite       5,155,426,304 bytes
~/.codex/logs_2.sqlite-wal      21,440,512 bytes
~/.codex/logs_2.sqlite-shm          32,768 bytes

state_5.sqlite and the auth/state files were left untouched.

Reversible recovery

After resolving and stopping only the packaged Codex process tree, I moved these three files into a timestamped backup directory under ~/.codex/maintenance-backups/:

logs_2.sqlite
logs_2.sqlite-wal
logs_2.sqlite-shm

Then I relaunched the Store app and allowed it to create a fresh log DB.

Result

Before:

renderer_count=0
top_level_window_count=0

After the log DB rotation:

process_count=8
renderer_count=2
main_window_handle=nonzero
main_window_visible=true
main_process_responding=true

The UI appeared immediately and remained visible/responding on a follow-up check. The fresh logs_2.sqlite was recreated normally. The 5.15 GB database and sidecars remain available for rollback/private diagnostic collection.

This suggests startup should detect or tolerate an oversized/problematic logs_2.sqlite, and a supported doctor/recovery path could rotate only the log DB after confirming no relevant Codex processes are active. A broad Reset-AppxPackage or reinstall was not needed in this case.