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

Activity

1. jiangguangqi

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 1, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Jun 1, 2026
3. github-actions commented on Jun 1, 2026

   

   github-actionsBot

   on Jun 1, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Desktop can hang after enabling WSL app-server mode and requires Electron cache reset to recover #24404

   Powered by Codex Action
4. s110905 commented on Jun 12, 2026

   

   s110905

   on Jun 12, 2026

   More actions

   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.
5. zapabob commented on Jun 19, 2026

   

   zapabob

   on Jun 19, 2026

   More actions

   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:

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

   2. Wait 20 seconds.

   3. 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.
6. zapabob commented on Jun 19, 2026

   

   zapabob

   on Jun 19, 2026

   More actions

   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.
7. vspruyt commented on Jul 7, 2026

   

   vspruyt

   on Jul 7, 2026

   Last edited by vspruyt

   More actions

   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
   
   

   👍React with 👍1Reacted by J Jonah Jameson
8. laz-jamesfuller commented on Jul 17, 2026

   

   laz-jamesfuller

   on Jul 17, 2026

   More actions

   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.
9. lwz20210407 commented on Jul 24, 2026

   

   lwz20210407

   on Jul 24, 2026 – with ChatGPT Codex Connector

   More actions

   I encountered the same user-visible symptom after an in-app update, but with a distinct and well-captured Windows AppX container failure signature. I am adding the details because this appears to be another update/runtime lifecycle path to the same “background process, no GUI” outcome.

   Environment

   • OS: Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro)
   • Package: Microsoft Store / MSIX, OpenAI.Codex_2p2nqsd0c76g0
   • Executable: app\ChatGPT.exe
   • Affected transition: 26.715.10079.0 -> 26.721.3404.0
   • Current healthy version after recovery: 26.721.3996.0

   Sequence and observed behavior

   1. The app completed an in-app update, then would no longer show a window.
   2. A ChatGPT.exe process from the previous day remained alive in an abnormal state: one thread, about 2.3 GB working set, MainWindowHandle = 0, and no visible UI.
   3. Each launch attempt produced only a very small short-lived process. The behavior was consistent with a single-instance handoff to the stuck old process, after which the new process exited silently.
   4. Normal termination and non-elevated taskkill /F failed with access denied. An elevated taskkill /F /IM ChatGPT.exe removed the stale process.
   5. After the stale process was removed, AppX registration showed the new package version and Status = Ok. Re-registering AppxManifest.xml also succeeded.
   6. Launch still failed, now with repeatable AppModel Runtime errors:

   Event ID 208
   0x80070020: Cannot create the process for package
   OpenAI.Codex_26.721.3404.0_x64__2p2nqsd0c76g0 because an error was
   encountered while configuring runtime. [LaunchProcess]
   
   Event ID 215
   0x80070020: Cannot create the Desktop AppX container for package
   OpenAI.Codex_26.721.3404.0_x64__2p2nqsd0c76g0 because an error was
   encountered converting the job.
   

   There were 52 matching Event 208/215 records between 09:44 and 10:53 on the affected day. 0x80070020 is ERROR_SHARING_VIOLATION.

   Lock investigation

   • Restart Manager reported no user-mode locks on ChatGPT.exe or the core package DLLs.
   • A scan of loaded process modules found no process still loading DLLs from the Codex package.
   • No remaining user-mode Codex/ChatGPT process was running.
   • The package's virtual registry hives were nevertheless still mounted under a residual \REGISTRY\WC\Silo... namespace.
   • The backing package files included SystemAppData\Helium\User.dat, UserClasses.dat, and a package cache .dat hive.
   • Restart Manager identified the holders of User.dat as PID 4 (System) and the Windows Registry process, both critical system processes. This is consistent with a still-mounted package/container hive rather than an ordinary file handle from another application.
   • Restarting AppXSvc did not release the hive. Resetting the app data could not replace the locked hive file.

   Other MSIX apps on the same machine also had mounted virtual registry hives and launched normally, so “hive mounted” by itself is not the problem. The Codex-specific failure was the inability to create/convert the Desktop AppX container while the previous container state remained present.

   Recovery

   A full Windows restart cleared the stale container/session state. The app then launched normally. Logging out and back in would likely have the same effect, but only reboot was verified.

   The Codex CLI continued to work throughout because it did not depend on this Desktop AppX container activation path.

   Interpretation (not claiming proven causality)

   The evidence shows two consecutive failures around the update:

   1. an old version process remained stuck and intercepted subsequent single-instance launches;
   2. after that process was terminated, new-version activation failed while Windows still retained the package container/virtual-registry state.

   It is not proven whether force-terminating the process created the residual container state, or whether the update/hang had already left the container inconsistent. The failure is best described as an update + process/container lifecycle race until the responsible component is confirmed.

   I have also seen reports from multiple other users describing the same top-level symptom immediately after desktop updates, although their underlying error code may differ.

   Suggested safeguards

   • Do not finalize activation of the new package version until the old main process and child processes have exited cleanly.
   • Add a timeout and stale-instance fallback to the single-instance wakeup handshake.
   • Detect Event 208/215 or 0x80070020 during activation and present an explicit “sign out or restart Windows to finish the update” recovery message instead of silently exiting.
   • Add update-time diagnostics around Desktop AppX container/job conversion and virtual registry hive teardown.

   Windows WER also contains earlier Codex hangs/crashes across several package versions on this machine (MoAppHang, MoBEX, MoAppCrash, and HamLkd), so this does not appear to be an isolated one-off event. I can provide the relevant .evtx exports or WER report IDs if maintainers need them.