Codex Desktop latest Windows version opens then exits immediately #25807

Activity

1. Godfather59

   added

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

   on Jun 2, 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 2, 2026
3. github-actions commented on Jun 2, 2026

   

   github-actionsBot

   on Jun 2, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop for Windows crashes immediately after launch (26.527.3686.0) #25501
   • codex Windows app startup crash. #25494
   • Windows app won't open after update, background process exists but no GUI window #25575

   Powered by Codex Action
4. shenhaitao010 commented on Jun 3, 2026

   

   shenhaitao010

   on Jun 3, 2026

   More actions

   me too, Codex Desktop latest Windows version opens then exits immediately
5. wvdweij commented on Jun 3, 2026

   

   wvdweij

   on Jun 3, 2026

   More actions

   Same here
6. qkd5996-sys commented on Jun 10, 2026

   

   qkd5996-sys

   on Jun 10, 2026

   More actions

   Same issue here, still broken on 26.608.1337.0 (Windows 11, Korean locale, dual monitor).

   Timeline: the app worked normally until this morning. It auto-updated to 26.608.1337.0 at ~09:47 (KST) and since then it exits immediately on launch — no window, no error dialog, no Application Error / WER events logged.

   Details that may help:

   • After each launch attempt, only a leftover extension-host process remains (spawned from %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\...) and it keeps a file lock on ~/.codex.
   • Tried with no effect: killing all leftover codex processes, renaming ~/.codex, renaming %LOCALAPPDATA%\OpenAI\Codex, launching Codex.exe directly from the WindowsApps package path, setting CODEX_HOME to an ASCII-only path (user profile name is non-ASCII Korean), disconnecting the second monitor, clean uninstall/reinstall (twice), reboot.
   • Chromium log (--enable-logging=file) shows a normal startup then a silent controlled teardown within ~1 second.
   • CLI (@openai/codex via npm) works fine on the same machine.

   👍React with 👍1Reacted by Jaepil.Choi
7. jaepil-choi commented on Jun 10, 2026

   

   jaepil-choi

   on Jun 10, 2026

   Last edited by jaepil-choi

   More actions

   @qkd5996-sys Hi man, another Korean here facing the same problem.
   It immediately crashes after launch and reinstalling it from Windows Store doesn't fix it.
   I also tried renaming ~/.codex to something else, but then it creates near-empty .codex/ and still crashes. (It only contains sqlite/codex-dev.db )
   My user profile name is also non-ASCII Korean like 홍길동.

   If you find a fix, please post and tag me.
8. qkd5996-sys commented on Jun 11, 2026

   

   qkd5996-sys

   on Jun 11, 2026

   More actions

   Fixed it on my machine. Sharing the root cause and workaround in case it helps others.

   Root cause
   On launch, the desktop app copies its bundled Computer-Use Node runtime from
   C:\Program Files\WindowsApps\OpenAI.Codex_<ver>_x64__2p2nqsd0c76g0\app\resources\cua_node (~115 MB, ~2000 files)
   into %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\.

   On this PC that bulk copy goes through the MSIX/VFS layer and dies with a native C++ exception (0xE06D7363), so the process tears itself down silently — no window, no Application Error, no WER report. Every launch (and every reinstall) re-attempts the same broken copy, which is why reinstalling never helped. The giveaway: the target folder only ever contained leftover staging dirs, never the finished folder:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\
     .staging-2f053e67fec2d258-AE1mBa
     .staging-2f053e67fec2d258-EmtEqp
     ... (6 of them)
   

   The app validates the destination before copying and skips the copy if a valid folder already exists. The final folder name is the hash embedded in the staging name (2f053e67fec2d258).

   Workaround — pre-stage the runtime yourself, outside the MSIX context, using normal PowerShell (this bypasses the broken VFS copy):

   $p   = (Get-AppxPackage OpenAI.Codex).InstallLocation
   $src = "$p\app\resources\cua_node"
   $base= "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node"
   # read the hash from any leftover staging dir, e.g. 2f053e67fec2d258
   $dst = "$base\2f053e67fec2d258"
   
   # remove failed staging dirs
   Get-ChildItem $base -Filter ".staging-*" -Force | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
   # copy via plain robocopy (not the app's MSIX copy path)
   robocopy $src $dst /E /R:1 /W:1

   After this the app launches normally and the window appears. (Note: the hash folder name is version-specific, so this may need redoing after an app update if the same crash returns.)

   Environment: Windows 11 Pro, Korean locale, app version 26.608.1337.0. CLI (@openai/codex) was unaffected throughout, which fits — the CLI doesn't stage this runtime.
9. wvdweij commented on Jun 11, 2026

   

   wvdweij

   on Jun 11, 2026

   More actions

   I fixed it by removing the global NODE_OPTIONS=--openssl-legacy-provider setting in my environment variables:

   You can check whether your system has this environment variable set:
   NODE_OPTIONS=--openssl-legacy-provider
   If it exists, try deleting it and then see if Codex launches normally.
10. jaepil-choi commented on Jun 14, 2026

    

    jaepil-choi

    on Jun 14, 2026

    More actions

    Hey guys, here's the fix.

    #27367 (comment)