Windows Codex App 26.609.4994.0 no longer opens after update

<img width="2578" height="594" alt="Image" src="https://github.com/user-attachments/assets/770c1093-e041-4b1c-b3f3-215092275fe2" />

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

• #27806
• #27858
• #27849
• #27781
• #27827

Powered by Codex Action

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.

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!

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.

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.

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.

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.

@MisterRound I did try exactly that, pointing to the cached WSL CLI, and while the app did launch, it's still unusable as the app is traversing the network to use the cached WSL CLI on Windows instead of the WSL-installed codex. Try it, it's unusable, actions/responses are taking over 10+ mins on simple requests.

Also, and as you have rightly and methodically documented in #25216, Codex App and WSL really need a dedicated path instead of continuous patch work that keeps breaking.

@SocialK sorry we've hijacked your thread

I hit this after the latest Windows app update as well, using Desktop in WSL mode.

In my case the app was failing around the Desktop-managed WSL Codex binary cache. The working path for WSL mode was:

C:\Users\Deependra\.codex\bin\wsl\codex

Important detail: even though this is a Windows path, the file at that path is a Linux ELF binary, not codex.exe. The Windows Electron app appears to launch it via wsl.exe.

What worked for me:

1. Found that the top-level WSL cached binary was stale/broken:

C:\Users\Deependra\.codex\bin\wsl\codex

1. Found a newer cached binary under:

C:\Users\Deependra\.codex\bin\wsl\<hash>\codex

1. Copied the newer cached binary over the top-level one:

C:\Users\Deependra\.codex\bin\wsl\codex

1. Set/confirmed:

CODEX_CLI_PATH=C:\Users\Deependra\.codex\bin\wsl\codex

After that, Desktop WSL mode launched again. Logs showed:

spawnCommand=wsl.exe
executablePath=C:\Users\Deependra\.codex\bin\wsl\codex

and the binary was:

ELF 64-bit ...
codex-cli 0.140.0-alpha.2

So this may be related to the Windows app update not correctly repairing/updating the Desktop WSL binary cache.

same issue

<img width="544" height="167" alt="Image" src="https://github.com/user-attachments/assets/43830b01-5a36-4061-adb1-d84850e58eed" />

I believe I hit the same underlying issue and found an additional clue that may help narrow it down.

Initial Symptom

The problem actually started immediately after updating Codex Desktop.

On startup, Codex failed with an error similar to:

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

I recovered from this by manually setting CODEX_CLI_PATH to the existing codex.exe binary that was already present on disk.

After that, Codex started successfully, but the project chat issues described below appeared.

Symptoms After Startup Was Restored

• Projects were still visible.
• Project chat lists became empty.
• Global search could still find old chats.
• Opening chats from search worked.
• Some chats showed:

Current working directory is missing
The working directory for this chat no longer exists

Importantly, the data was not lost.

Investigation

The SQLite database (~/.codex/state_5.sqlite) still contained all threads.

Historical threads had cwd values like:

/mnt/d/Projects/ExampleProject

However, after the update, newly created chats in the same project were being stored with:

C:\mnt\d\Projects\ExampleProject

This path does not exist on a normal Windows installation.

As a result:

1. Existing threads no longer matched the project's current workspace root.
2. New chats were also associated with a non-existent path.
3. Search still worked because it appeared to query threads independently of project/workspace matching.

Workaround

As a temporary workaround, I:

1. Created junctions such as:

C:\mnt\d -> D:\
C:\mnt\c -> C:\

1. Normalized old /mnt/<drive>/... thread paths inside state_5.sqlite to match the new format.

After doing this, nearly all project chats reappeared.

One Additional Detail

I had previously configured the agent environment to use WSL by default, and many of my historical threads were created in that environment.

Because of that, my database contained thread cwd values like:

/mnt/d/Projects/ExampleProject

I cannot say whether this issue affects users who have never enabled WSL or have a clean installation without WSL configured.

It is possible that this only occurs when migrating existing thread history between WSL-based workspace roots and the newer Desktop path handling. In my case, the issue appeared immediately after an update and only affected project chat visibility. The underlying session data remained intact.

I don't know if WSL is the root cause or merely a prerequisite for triggering the bug.

Possible Root Cause

This looks like a regression involving both:

1. CLI path discovery during startup.
2. Workspace root normalization and matching between equivalent locations:

/mnt/d/Projects/ExampleProject
D:\Projects\ExampleProject
C:\mnt\d\Projects\ExampleProject

It may be helpful to canonicalize equivalent WSL and Windows paths before comparing workspace roots and to avoid persisting C:\mnt\<drive>\... paths unless those mappings actually exist on the machine.

Happy to provide additional diagnostics or database samples if needed.

have same problem
windows powershell with admin privileges and command

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

and it works again)

After updating to OpenAI Codex Windows App 26.609.4994.0, the app is no longer usable.

I cannot access the “About Codex” dialog because the main Codex window does not open, so I confirmed the installed version through PowerShell.

Environment:

• Product: OpenAI Codex Windows Desktop App
• 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
• Package status: Ok
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Subscription: ChatGPT Pro
• Normal setup: native Windows / PowerShell

Actual behavior:

• Codex does not open the main UI window.
• The Codex tray icon appears in the Windows system tray.
• System load increases after launching it.
• No visible error message appears.
• Clicking the taskbar/tray icon does not bring up the main Codex window.
• The app remains unusable because I cannot access the main UI or my existing Codex work/history.

Expected behavior:

• Codex Windows App should launch normally.
• The main UI window should appear.
• Existing Codex sessions/projects should be accessible.

Read-only diagnostics I ran:

1. AppX package

PowerShell reports:

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

The install location exists.

1. Bundled Codex CLI exists

The bundled CLI exists at:

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

File metadata:

• Size: 280,658,224 bytes
• LastWriteTime: 6/12/2026 12:51:21 AM
• Attributes: Archive

1. ACL permissions do not look obviously broken

ACL permissions for app\resources\codex.exe include ReadAndExecute for:

• BUILTIN\Users
• APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
• NT AUTHORITY\RESTRICTED
• NT AUTHORITY\LOCAL SERVICE
• NT AUTHORITY\NETWORK SERVICE

So this does not look like a missing bundled codex.exe file or a simple missing ReadAndExecute permission issue.

1. CODEX_CLI_PATH is empty

PowerShell output:

• User_CODEX_CLI_PATH: empty
• Machine_CODEX_CLI_PATH: empty
• Process_CODEX_CLI_PATH: empty

I have not manually set CODEX_CLI_PATH.

1. WSL is not installed/enabled

I checked the WSL hypothesis mentioned in the comments.

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.

1. WebView2 information

Microsoft Edge WebView2 Runtime directory:

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

Visible entries:

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

A msedgewebview2.exe process from version 149.0.4022.62 is visible in the process list, although from the basic process table alone I cannot prove whether that specific process belongs to Codex.

1. Crashpad reports

The Crashpad reports directory contains .dmp files under:

C:\Users\myname\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

However, the latest visible .dmp files I saw are from 6/8 and 6/9, not from the current 6/13 launch attempts. So the current behavior may not be an instant crash anymore. It looks more like the app starts in the background/tray but the main UI window / renderer never appears.

Current hypothesis:

Codex Windows App 26.609.4994.0 may be hanging or failing during one of these startup stages:

• main window creation
• renderer / WebView / Electron-style initialization
• shell environment loading
• internal bundled CLI path resolution
• window restore / hidden window state
• Windows AppX / MSIX wrapper startup

Important clarification:

This does not look like a WSL / CODEX_CLI_PATH issue on my machine because WSL is disabled and no WSL package is installed.

Request:

Please investigate Codex Windows App 26.609.4994.0 as a Windows Desktop App startup / main-window / renderer regression. If this is a known regression, please provide a workaround, rollback path, or hotfix build.

I can provide sanitized logs or dump files if needed, but I do not want to publicly upload files that may contain local paths, auth/session references, or project data.

I have the same problem. Disabling WSL mode won't work well, because I have all my projects set up to wsl... This is 3rd time during the last 2 months that My Codex gets broken after update. Vibe coders department of OpenAI should probably try to use regression skills?!

I also pay 200 usd a month btw...

I want to add that this is not an isolated inconvenience for me.

In the last two weeks, I lost my active Codex work three separate times. This is not just about tokens or rate limits. Entire work sessions disappeared or became inaccessible while I was actively working on them.

I am paying $200/month for ChatGPT Pro, and right now I cannot even reliably open the Codex Windows App. But honestly, the most painful part is not even the broken Windows app. The bigger problem is that GPT-5.5 inside Codex has stopped being reliable for real coding work.

I have seen tasks run for many hours, sometimes close to 10 hours, while making only a few actual file edits. Codex appears to get stuck in loops: reading the same files again, compacting context, reconnecting, and continuing without meaningful progress. Issue: https://github.com/openai/codex/issues/27588

This needs loop detection / no-progress detection. A paid coding agent should not spend hours “working” while producing almost nothing and consuming paid usage.

Same problem, I have read about 10 threads, this one is "most" living

For those with the broken Codex/WSL install - the workaround at #28074 gets you back on track until the regression is fixed.

I’m experiencing what appears to be the same issue on Windows Codex App 26.609.4994.0.

Environment:

• OS: Windows 11 Pro
• Codex Windows App version: 26.609.4994.0
• Main Windows user profile path contains Korean characters: C:\Users\최준서
• A newly created English-only Windows test account, codex_test, can launch the Codex Desktop app normally.

Symptoms:

• On my main Windows account, the Codex Desktop app does not open.
• The process starts briefly and exits before the main window appears.

Diagnostics:

• codex doctor: 17 ok · 0 warn · 0 fail
• Auth is configured and valid.
• State/log/goals/memories SQLite DB integrity checks are OK.
• Threads inventory is consistent.
• WebSocket connectivity is OK.
• ripgrep is installed and search check passes.
• MCP servers are disabled / 0 configured.
• codex app-server --listen ws://127.0.0.1:4500 starts successfully.
• http://127.0.0.1:4500/readyz returns 200 OK.
• codex --remote ws://127.0.0.1:4500 connects successfully.
• Launching the Desktop app directly exits with code -529697949.
• Launching with --user-data-dir=C:\CodexElectronProfile still exits with the same code.
• The direct launch log includes a garbled user path similar to:

C:\Users\理쒖???AppData\Roaming\Codex\web\Codex

This suggests that CLI, app-server, auth, database, network, and model access are working correctly, and the failure is isolated to the Windows Desktop Electron UI layer. It may be related to non-ASCII/Korean Windows user profile paths or a regression in version 26.609.4994.0.

Please let me know if there is a known workaround, rollback, or upcoming hotfix.

Adding another Windows + WSL-mode datapoint for 26.609.4994.0. This looks related to the bundled CLI discovery regression, but there is a second failure mode after using CODEX_CLI_PATH as a workaround.

Environment:

• Windows Store package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
• Installed package status: Ok
• WSL is present: Ubuntu-24.04 / WSL2
• Codex data is under the normal Windows home, e.g. %USERPROFILE%\.codex

Package/resource inspection:

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

Normal launch fails before the main app can initialize:

bundled_executable_relocation_failed
sourcePath=C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\codex
operation=stat_source
errorCode=ENOENT

[AppServerConnection] 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."

Directly executing the bundled Windows CLI also fails from PowerShell:

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\codex.exe --version
Program 'codex.exe' failed to run: Access is denied
FullyQualifiedErrorId: NativeCommandFailed

Workaround used on this machine:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  "C:\Users\<redacted>\Downloads\codex-x86_64-pc-windows-msvc (1).exe",
  "User"
)

With that workaround, the Desktop app does launch and initializes an external app-server:

stdio_transport_spawned executablePath="C:\Users\<redacted>\Downloads\codex-x86_64-pc-windows-msvc (1).exe"
Current reported app-server version: currentVersion=0.139.0
initialize_handshake_result outcome=success
Codex CLI initialized

However, after this workaround the app is still not fully healthy. thread/list succeeds, and the local session data still exists on disk, but plugin/list repeatedly fails:

method=thread/list errorCode=null
method=plugin/list errorCode=-32600
Request failed error={"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}

There are also path-normalization symptoms after the workaround. The app tries to watch Windows paths of the form:

C:\mnt\c\Users\<redacted>\Documents\Codex\...
C:\mnt\d\...

Those paths do not exist on this Windows install; the real paths are C:\Users\... / D:\..., while WSL paths are /mnt/c/... / /mnt/d/.... The log then reports ENOENT from git-init-watcher.

Observed impact:

• App cannot start normally without CODEX_CLI_PATH.
• The workaround can bring up the window, but plugin/app features are partially broken.
• Existing session files are still present, and thread/list succeeds, but the UI/history behavior is unreliable in this mixed state.

This may be two related regressions:

1. WSL-mode bundled resource relocation expects extensionless resources\codex / resources\rg, but the Windows Store package contains only codex.exe / rg.exe.
2. After forcing an external Windows CLI through CODEX_CLI_PATH, Desktop and CLI path handling disagree on absolute path bases, causing AbsolutePathBuf deserialized without a base path and invalid C:\mnt\... workspace roots.

Happy to provide more sanitized log snippets if helpful.

https://github.com/openai/codex/issues/28212#issuecomment-4703996879

The workaround that worked for me was to point CODEX_CLI_PATH to the Desktop-managed WSL cached Codex binary.

The important part is that CODEX_CLI_PATH should not point to the Windows npm codex.cmd path, and should not point to the WSL-installed /home/.../codex path. It should point to the Codex Desktop-managed WSL cached binary under:

%USERPROFILE%\.codex\bin\wsl\<cache-hash>\codex

First, I checked whether such a cached WSL binary existed:

Get-ChildItem "$env:USERPROFILE\.codex\bin\wsl" -Recurse -File -Filter codex -ErrorAction SilentlyContinue |
Select-Object FullName, Length, LastWriteTime

This returned a path like:

C:\Users\<redacted>\.codex\bin\wsl\<cache-hash>\codex

Then I set CODEX_CLI_PATH to that cached WSL binary:

$CodexWslPath = "$env:USERPROFILE\.codex\bin\wsl\<cache-hash>\codex"

Test-Path $CodexWslPath

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $CodexWslPath, "User")
$env:CODEX_CLI_PATH = $CodexWslPath

reg query HKCU\Environment /V CODEX_CLI_PATH

Test-Path should return:

True

After that, I closed any running Codex processes:

Get-Process | Where-Object {$_.ProcessName -like "*Codex*"} |
Stop-Process -Force -ErrorAction SilentlyContinue

Then I restarted Codex Desktop. After this, Codex Desktop launched successfully again in WSL mode.

For clarity, this is different from pointing CODEX_CLI_PATH to a Windows npm path such as:

C:\Program Files\nodejs\codex.cmd

That path did not work for me, because it can be interpreted incorrectly in the WSL/Linux execution context.

This workaround appears to rely on an existing Desktop-managed WSL cached binary. After an official fix is released, I plan to remove the manual CODEX_CLI_PATH override so that Codex Desktop can return to its normal managed path resolution:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")
Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue
reg query HKCU\Environment /V CODEX_CLI_PATH

If the final registry query reports that the value does not exist, the manual override has been removed.

This appears to be affecting many users, so we're treating it as a high priority to get it fixed.

#28212 (comment) The workaround that worked for me was to point CODEX_CLI_PATH to the Desktop-managed WSL cached Codex binary. The important part is that CODEX_CLI_PATH should not point to the Windows npm codex.cmd path, and should not point to the WSL-installed /home/.../codex path. It should point to the Codex Desktop-managed WSL cached binary under: `` %USERPROFILE%\.codex\bin\wsl\<cache-hash>\codex ` First, I checked whether such a cached WSL binary existed: Get-ChildItem "$env:USERPROFILE\.codex\bin\wsl" -Recurse -File -Filter codex -ErrorAction SilentlyContinue | Select-Object FullName, Length, LastWriteTime This returned a path like: ` C:\Users\<redacted>\.codex\bin\wsl\<cache-hash>\codex ` Then I set CODEX_CLI_PATH to that cached WSL binary: $CodexWslPath = "$env:USERPROFILE\.codex\bin\wsl\<cache-hash>\codex" Test-Path $CodexWslPath [Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $CodexWslPath, "User") $env:CODEX_CLI_PATH = $CodexWslPath reg query HKCU\Environment /V CODEX_CLI_PATH Test-Path should return: ` True `` After that, I closed any running Codex processes: Get-Process | Where-Object {$_.ProcessName -like "Codex"} | Stop-Process -Force -ErrorAction SilentlyContinue Then I restarted Codex Desktop. After this, Codex Desktop launched successfully again in WSL mode.

worked for me, thank you

Same issue on Windows 11 with OpenAI.Codex 26.609.4994.0.

The app launches, but freezes completely when opening/starting a chat and entering a message. Windows Event Viewer shows MoAppHang / Application Hang:

P1: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Codex.exe version: 149.0.7827.54

WSL_DISTRO_NAME is empty for User and Machine.
USERPROFILE and LOCALAPPDATA contain only ASCII characters.
Reset-AppxPackage and cleaning .codex / LocalCache did not fix it.

This appears to be affecting many users, so we're treating it as a high priority to get it fixed.

Thanks Eric. I believe the best way forward is to maintain two separate Windows builds of the Codex app: Stable and Beta.

The main release app should be treated as the stable channel and should only include verified fixes, patches, and thoroughly tested updates. At the moment, however, the main Codex app on the Microsoft Store is unstable and frequently breaks, with alpha-level Codex builds, recurring bugs, and regressions appearing across releases. This is not conducive to a productive workflow, especially for users relying on Codex for regular development work.

The Beta app is the appropriate place for testing new functionality, experimental builds, and early Codex changes. That would allow users who want to test new features to do so, while keeping the main app reliable for regular use.

In short, the main app should prioritize stability and confidence, while the Beta app can continue to serve as the testing channel.

And, as Donny would say, thank you for your attention to this matter. Now let’s make Codex stable on Windows and WSL 🚀

After the huge 150 MB update, nothing has changed. The app is still unusable: it causes my computer to heat up, memory usage reaches 99%, sessions do not load, and the entire interface is extremely laggy.

Update after the new Microsoft Store package installed today:

Current versions:

• Microsoft Store / Windows package version:

OpenAI.Codex 26.611.8273.0
PackageFullName: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0

• In-app About Codex dialog:

Version 26.611.61753 • Released Jun 17, 2026

• Codex.exe FileVersion / ProductVersion:

149.0.7827.115

Result after retesting:

The regression is still not fixed.

Current behavior:

• Codex now takes around 60 seconds before it becomes usable after launch.
• Before these recent regressions, around one month ago, the app opened almost instantly.
• The user interface is still laggy.
• Old sessions / project chats still do not appear or open.
• Existing work history remains effectively inaccessible.
• System memory usage is still extremely high: around 89% RAM (32gb)
• CPU usage is also elevated: around 24% CPU, roughly 10 percentage points higher than my normal baseline was.
• The taskbar icon still shows an unexplained badge “1”.
• The app opens, but there is effectively nothing usable inside because the previous sessions do not load and everything is in a huge lag

Conclusion:

The new package 26.611.8273.0 / in-app version 26.611.61753 does not fix the core issue. It only changes the failure mode again.

This still appears to be a Windows Codex Desktop regression involving local session/history loading, indexing, migration, renderer performance, or memory management.

Please attach this update to the internal tracking item and escalate it to the Windows desktop/session-history engineering team.