Windows Codex App 26.609.4994.0 no longer opens after update

[SocialK]

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

Update from 12th of June, About Dialog is no longer availble as app do not open anymore!

What subscription do you have?

ChatGPT Pro / 200

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating to OpenAI Codex Windows App 26.609.4994.0, the app no longer opens at all.

I cannot access the “About Codex” dialog because the application does not launch anymore, so I confirmed the installed version through PowerShell.

Installed package information:

Name: OpenAI.Codex
Version: 26.609.4994.0
PackageFullName: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
InstallLocation: C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Status: Ok

Subscription: ChatGPT Pro

Actual behavior:

• After the update to 26.609.4994.0, Codex no longer opens.
• Launching the app does not show the main window.
• I cannot reach the “About Codex” dialog.
• I cannot access my existing Codex work/history from the Windows app.
• The issue started immediately after this update.
• The installed AppX package status is “Ok”, but the app itself is unusable.

Expected behavior:

• Codex Windows App should launch normally.
• The main UI should appear.
• I should be able to access my existing Codex sessions/projects.

Diagnostics already collected:

• AppX package information
• Crashpad report list
• Local OpenAI/Codex file list
• .codex file list
• Windows Event Viewer logs can be provided if needed

Important observation:
The Crashpad reports directory contains multiple report entries under:
C:\Users\parto\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

This looks like a startup crash/regression in the Windows desktop app, not a missing installation.

Privacy note:
Some local diagnostic files may include sensitive local paths, session references, auth files, or project data, so I can provide sanitized logs/dumps if needed.

Impact:
This is a complete blocker. I cannot use the Codex Windows App at all after the latest update.

Request:
Please investigate the 26.609.4994.0 Windows build. If this is a known regression, please provide a workaround, rollback path, or hotfix build.

What steps can reproduce the bug?

Actual behavior:

• The Codex app no longer opens.
• Launching the app does not show the main window.
• This started immediately after the update to 26.609.4994.0.

Expected behavior:

• Codex Desktop should launch normally and show the main window.

What is the expected behavior?

No response

Additional information

No response

[SocialK]

[github-actions]

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

• Windows app crashes immediately after launch (26.609.3341.0) #27806
• Windows Codex app 26.609.3341.0 exits silently on launch #27858
• Codex Desktop for Windows 26.609.3341.0 exits immediately after launch #27849
• Windows Desktop exits immediately after 26.609.3341.0 update #27781
• Stable Codex Desktop 26.609.3341.0 exits immediately on Windows after update; Beta works #27827

Powered by Codex Action

[SocialK]

Additional runtime information:

I checked the Microsoft Edge WebView2 Runtime folder on this machine.

PowerShell output shows:

C:\Program Files (x86)\Microsoft\EdgeWebView\Application

Directory entries:

• SetupMetrics — LastWriteTime: 6/12/2026 12:20:28 PM
• 149.0.4022.62 — LastWriteTime: 6/11/2026 12:05:36 PM

This appears to be in the same time window as the Codex Windows App 26.609.x update and the startup crash.

I am not claiming WebView2 is definitely the root cause, but please check whether Codex Windows App 26.609.4994.0 has a startup regression related to the interaction between:

• Microsoft Edge WebView2 Runtime 149.0.4022.62
• the 26.609.x MSIX Windows package
• local Codex runtime staging under AppData\Local\OpenAI\Codex\runtimes
• CUA node / Chromium / Electron-style initialization
• Windows AppX / MSIX sandbox initialization

My platform output is:

Microsoft Windows NT 10.0.26200.0 x64

The Windows user profile path is ASCII-only:

C:\Users\englishname

So this does not look like a non-ASCII user-profile-path issue.

[cyformatician]

Garbage windows builds, one regression or newly introduced bug after the other = total loss of productivity. In my case, the latest update via the store broke the app because it is set in WSL agent mode and is missing a CODEX_CLI_PATH env variable rendering the app unusable as it fails to start unless WSL mode is reverted to native mode.

I may have missed it, but are you using Codex with WSL?

OpenAI team - what's going on? I really don't get the hate for Windows/WSL!

[SocialK]

I checked this. WSL is not installed/enabled on my machine.

PowerShell output:
Microsoft-Windows-Subsystem-Linux: Disabled

Also, Get-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux returns no installed package.

So I was not using Codex in WSL agent mode. My setup is native Windows / PowerShell. This looks like a native Windows Codex App startup crash on 26.609.4994.0, not a WSL / CODEX_CLI_PATH issue.

[cyformatician]

Native mode runs fine here, system running 25H2 / 26200.8655 Windows build. Try the Codex Beta app, if that fails too then it must be system/OS related.

[shuncleopasfang]

I’m seeing the same issue after updating Codex App to 26.609.4994.0 on Windows 11 with WSL mode enabled.

The app fails with:

Codex failed to start.
Unable to locate the Codex CLI binary.
Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

In my case, the diagnostics show that a non-login WSL shell resolves codex to the Windows path:

wsl -e bash -c 'command -v codex || echo NOT_FOUND'

Output:

/mnt/c/Program Files/nodejs/codex

But a login shell finds the correct WSL Codex:

wsl -e bash -lc 'command -v codex; codex --version; command -v bwrap || true'

Output:

/home/<redacted>/.npm-global/bin/codex
codex-cli 0.139.0

So this looks like the app is starting WSL in a non-login shell after the update, causing it to pick up the Windows Codex path instead of the WSL-installed Codex. This seems related to #22423, but in my case it started immediately after updating to 26.609.4994.0.

[MisterRound]

Adding a Windows + WSL-mode datapoint with root-cause evidence from local logs/package inspection. Paths/usernames are redacted.

Environment:

• Codex Windows Store package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
• WSL mode enabled (runCodexInWindowsSubsystemForLinux=true, integrated terminal shell set to WSL)
• A previously cached WSL Codex CLI was present and executable: codex-cli 0.140.0-alpha.2

Startup failure shown by the app:

Codex failed to start.
Unable to locate the Codex CLI binary.
Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

Relevant desktop log evidence:

bundled_executable_relocation_failed
destinationPath=C:\Users\<WindowsUser>\.codex\bin\wsl\codex
sourcePath=C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\codex
errorCode=ENOENT
operation=stat_source

app_server_connection.transport_connect_failed
errorMessage="Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."

Package inspection on the installed MSIX showed that the Windows package contains Windows resource binaries, but not the WSL/Linux resource names the WSL relocation path is trying to stat:

app\resources\codex.exe   exists
app\resources\rg.exe      exists
app\resources\codex       missing
app\resources\rg          missing

That makes this case different from, or at least earlier than, a WSL non-login-shell/PATH lookup failure. In this repro, Desktop failed before it could spawn a WSL CLI because it attempted to relocate a package resource that is not present in the installed package.

Confirmed workaround:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  "C:\Users\<WindowsUser>\.codex\bin\wsl\<cache-hash>\codex",
  "User"
)

After closing/reopening Codex with CODEX_CLI_PATH pointed at the existing cached WSL CLI, the app launched and initialized successfully:

stdio_transport_spawned executablePath=C:\Users\<WindowsUser>\.codex\bin\wsl\<cache-hash>\codex
initialize_handshake_result durationMs=1599 outcome=success
Codex CLI initialized

Suggested fixes:

• Include the WSL/Linux resource binaries expected by WSL mode (app\resources\codex, likely app\resources\rg) in the Windows Store/MSIX package, or avoid hard-failing when those resources are missing and a managed/cached WSL CLI already exists.
• Make the CODEX_CLI_PATH guidance explicit for WSL mode, including that it can point to the Windows-visible path for the cached WSL binary.
• Improve the launch error so it distinguishes “missing package resource” from “WSL PATH / shell discovery failed”; right now both collapse into the same CLI-not-found message.

Temporary workaround caveat: setting CODEX_CLI_PATH this way pins Desktop to that cached CLI until the variable is removed.