›_ Codex Issues
Codex Issues / #25807

Codex Desktop latest Windows version opens then exits immediately

Open 💬 8 comments Opened Jun 2, 2026 by Godfather59
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

OpenAI.Codex 26.527.3686.0

What subscription do you have?

PLUS

What platform is your computer?

Windows

What issue are you seeing?

  • I click Codex Desktop / run codex app
  • Windows starts the app
  • No window appears
  • Process exits immediately

Logs:

  • AppModel Runtime shows process created for OpenAI.Codex_2p2nqsd0c76g0!App
  • Then Desktop AppX container is destroyed immediately
  • TWinUI activation says operation completed successfully
  • No Application Errors are logged

Important:
Older Codex Desktop version works. The issue appears only after the latest update.

What steps can reproduce the bug?

Try to open it

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25501
  • #25494
  • #25575

Powered by Codex Action

shenhaitao010 · 1 month ago

me too, Codex Desktop latest Windows version opens then exits immediately

wvdweij · 1 month ago

Same here

qkd5996-sys · 1 month ago

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.
jaepil-choi · 1 month ago

@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.

qkd5996-sys · 1 month ago

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.

wvdweij · 1 month ago

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.

jaepil-choi · 1 month ago

Hey guys, here's the fix.

https://github.com/openai/codex/issues/27367#issuecomment-4691589493