WSL integration broken even with fresh installs

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

• #28031

Powered by Codex Action

I have same problem, is there any solution?

I have same problem, is there any solution?

that s how i temporarily fixed it with codex. the guide is written by codex after we solved it

Use this as the repair note for another Codex agent.

# Codex Desktop Windows/WSL startup repair

Symptom after Codex Desktop update:

- Windows dialog: `Codex failed to start`
- Message: `Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.`
- Intended setup: Codex Desktop should run the agent in WSL, not PowerShell.

## Likely root cause

The Windows Desktop update installed a package whose `app/resources` contained only Windows helper binaries:

- `codex.exe`
- `rg.exe`

but WSL mode expected extensionless Linux helper binaries:

- `codex`
- `rg`

Because Desktop could not find the Linux helper, later repair attempts may accidentally point `CODEX_CLI_PATH` at a Windows `codex.exe`. That makes Desktop launch a Windows binary through WSL interop, causing hybrid path bugs, plugin failures, SQLite/state errors, and agents trying to work in Windows/PowerShell.

Official Codex behavior to remember:

- Windows Desktop uses `%USERPROFILE%\.codex` as its Codex home.
- WSL CLI normally uses Linux `~/.codex`.
- Switching the Desktop agent to WSL requires an app restart.
- `CODEX_HOME` changes where Codex reads config/state, so leaking Windows `CODEX_HOME` into WSL can cause plugin/path issues.

## Repair steps

Close all Codex Desktop windows first.

### 1. Check the broken Desktop package

In PowerShell:

```powershell
Get-ChildItem "C:\Program Files\WindowsApps" -Directory |
  Where-Object Name -like "OpenAI.Codex_*" |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1 FullName

Then inspect its resources folder:

Get-ChildItem "C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources" |
  Where-Object Name -in "codex","codex.exe","rg","rg.exe" |
  Select-Object Name,FullName

If WSL mode is broken and only codex.exe / rg.exe exist, that matches this issue.

2. Make sure WSL helper binaries exist

In WSL:

ls -l /mnt/c/Users/$USER/.codex/bin/wsl/codex /mnt/c/Users/$USER/.codex/bin/wsl/rg
/mnt/c/Users/$USER/.codex/bin/wsl/codex --version

If those files do not exist, copy known-good Linux codex and rg binaries there from a working install/package, then:

chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex
chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/rg

3. Create a WSL wrapper

Create this file:

C:\Users\<WindowsUser>\.codex\bin\wsl\codex-desktop-wsl

Contents:

#!/usr/bin/env sh
unset CODEX_HOME
exec /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex "$@"

Then from WSL:

chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex-desktop-wsl

The important part is unset CODEX_HOME. It prevents Desktop’s Windows Codex home from leaking into the Linux app-server process.

4. Point Desktop at the wrapper

In PowerShell:

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

Then fully restart Codex Desktop.

5. Verify Desktop is launching WSL correctly

After restart, check the Desktop process command line from PowerShell:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match 'codex.*app-server|wsl.exe' } |
  Select-Object ProcessId,CommandLine

The good shape is:

wsl.exe ... exec /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex-desktop-wsl app-server ...

The bad shape is:

exec /mnt/c/Users/<WindowsUser>/AppData/Local/OpenAI/Codex/bin/.../codex.exe app-server

If you see codex.exe inside the WSL launch command, it is still using the Windows binary.

6. Re-select WSL in Desktop settings

Open Codex Desktop settings and set the agent runtime back to WSL.

Then restart the app again. The setting may temporarily revert to Windows after the failed startup, so this final restart matters.

Rollback

To remove the override later:

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $null, 'User')

Only do this after an upstream Desktop update restores proper WSL helper binaries in the app resources.

I have same problem, is there any solution?

You cneed to downgrade codex - i just downgraded codex. the newest update broke WSL i.e agennt enviroment

> I have same problem, is there any solution? that s how i temporarily fixed it with codex. the guide is written by codex after we solved it Use this as the repair note for another Codex agent. # Codex Desktop Windows/WSL startup repair Symptom after Codex Desktop update: - Windows dialog: Codex failed to start - Message: Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex. - Intended setup: Codex Desktop should run the agent in WSL, not PowerShell. ## Likely root cause The Windows Desktop update installed a package whose app/resources contained only Windows helper binaries: - codex.exe - rg.exe but WSL mode expected extensionless Linux helper binaries: - codex - rg Because Desktop could not find the Linux helper, later repair attempts may accidentally point CODEX_CLI_PATH at a Windows codex.exe. That makes Desktop launch a Windows binary through WSL interop, causing hybrid path bugs, plugin failures, SQLite/state errors, and agents trying to work in Windows/PowerShell. Official Codex behavior to remember: - Windows Desktop uses %USERPROFILE%\.codex as its Codex home. - WSL CLI normally uses Linux ~/.codex. - Switching the Desktop agent to WSL requires an app restart. - CODEX_HOME changes where Codex reads config/state, so leaking Windows CODEX_HOME into WSL can cause plugin/path issues. ## Repair steps Close all Codex Desktop windows first. ### 1. Check the broken Desktop package In PowerShell: ``powershell Get-ChildItem "C:\Program Files\WindowsApps" -Directory | Where-Object Name -like "OpenAI.Codex_*" | Sort-Object LastWriteTime -Descending | Select-Object -First 1 FullName Then inspect its resources folder: Get-ChildItem "C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources" | Where-Object Name -in "codex","codex.exe","rg","rg.exe" | Select-Object Name,FullName If WSL mode is broken and only codex.exe / rg.exe exist, that matches this issue. ### 2. Make sure WSL helper binaries exist In WSL: ls -l /mnt/c/Users/$USER/.codex/bin/wsl/codex /mnt/c/Users/$USER/.codex/bin/wsl/rg /mnt/c/Users/$USER/.codex/bin/wsl/codex --version If those files do not exist, copy known-good Linux codex and rg binaries there from a working install/package, then: chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/rg ### 3. Create a WSL wrapper Create this file: ` C:\Users\<WindowsUser>\.codex\bin\wsl\codex-desktop-wsl ` Contents: #!/usr/bin/env sh unset CODEX_HOME exec /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex "$@" Then from WSL: chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex-desktop-wsl The important part is unset CODEX_HOME. It prevents Desktop’s Windows Codex home from leaking into the Linux app-server process. ### 4. Point Desktop at the wrapper In PowerShell: [Environment]::SetEnvironmentVariable( 'CODEX_CLI_PATH', 'C:\Users\<WindowsUser>\.codex\bin\wsl\codex-desktop-wsl', 'User' ) Then fully restart Codex Desktop. ### 5. Verify Desktop is launching WSL correctly After restart, check the Desktop process command line from PowerShell: Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'codex.*app-server|wsl.exe' } | Select-Object ProcessId,CommandLine The good shape is: ` wsl.exe ... exec /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex-desktop-wsl app-server ... ` The bad shape is: ` exec /mnt/c/Users/<WindowsUser>/AppData/Local/OpenAI/Codex/bin/.../codex.exe app-server ` If you see codex.exe` inside the WSL launch command, it is still using the Windows binary. ### 6. Re-select WSL in Desktop settings Open Codex Desktop settings and set the agent runtime back to WSL. Then restart the app again. The setting may temporarily revert to Windows after the failed startup, so this final restart matters. ## Rollback To remove the override later: [Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $null, 'User') Only do this after an upstream Desktop update restores proper WSL helper binaries in the app resources.

I hit the same WSL startup failure on Windows with Codex Desktop 26.609.4994.0.

One thing that tripped me up: I had previously set this in config.toml so the app could start again:

runCodexInWindowsSubsystemForLinux = false

That is only a recovery step to get Desktop unstuck in Windows mode. Before testing the WSL repair, it has to be set back to:

runCodexInWindowsSubsystemForLinux = true

or Desktop will try to spawn the WSL wrapper as a Windows executable and fail.

The other issue was line endings in my wrapper. With CRLF endings I got:

code 127 signal null
/usr/bin/env: 'sh\r': No such file or directory

The working wrapper was:

#!/usr/bin/env sh
unset CODEX_HOME
exec /mnt/c/Users/<user>/.codex/bin/wsl/codex "$@"

saved with Unix LF endings at:

C:\Users\<user>\.codex\bin\wsl\codex-desktop-wsl

And my Windows user env var was:

[Environment]::SetEnvironmentVariable(
  'CODEX_CLI_PATH',
  'C:\Users\<user>\.codex\bin\wsl\codex-desktop-wsl',
  'User'
)

So the full working state was: WSL mode enabled again in config.toml, CODEX_CLI_PATH pointing at the wrapper, and the wrapper saved with LF endings.

I can confirm that the workaround presented by @andreidita22 works, and that the additons by @mosesadewale are spot on!
I got my Codex App running again. As I was more aggressive in my "repair" attempts (including full reinstall and actually wiping .codex folders, I "lost" my chats (I had backups). Should this have happened to anybody: Simply ask Codex to import the chats back into the new .codex folders. It could do that for me ok, just with a simple "Can you bring my chats back from these backups" and a bit of Python it wrote.

Let's hope though that by tomorrow a new version gets out that won't have this issue./

I just tried installing Codex Beta from Windows Store. Seem to not to be much broken currently and uses same config / history. Anyway hope the "stable" branch gets fixed soon.

<img width="848" height="265" alt="Image" src="https://github.com/user-attachments/assets/9ddd37ee-5138-48e3-9ab7-3b5845874a45" />

Still broken for me too

> > I have same problem, is there any solution? > > > that s how i temporarily fixed it with codex. the guide is written by codex after we solved it > Use this as the repair note for another Codex agent. > # Codex Desktop Windows/WSL startup repair > Symptom after Codex Desktop update: > > Windows dialog: Codex failed to start > Message: Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex. > Intended setup: Codex Desktop should run the agent in WSL, not PowerShell. > > ## Likely root cause > The Windows Desktop update installed a package whose app/resources contained only Windows helper binaries: > > codex.exe > rg.exe > > but WSL mode expected extensionless Linux helper binaries: > > codex > rg > > Because Desktop could not find the Linux helper, later repair attempts may accidentally point CODEX_CLI_PATH at a Windows codex.exe. That makes Desktop launch a Windows binary through WSL interop, causing hybrid path bugs, plugin failures, SQLite/state errors, and agents trying to work in Windows/PowerShell. > Official Codex behavior to remember: > > Windows Desktop uses %USERPROFILE%\.codex as its Codex home. > WSL CLI normally uses Linux ~/.codex. > Switching the Desktop agent to WSL requires an app restart. > CODEX_HOME changes where Codex reads config/state, so leaking Windows CODEX_HOME into WSL can cause plugin/path issues. > > ## Repair steps > Close all Codex Desktop windows first. > ### 1. Check the broken Desktop package > In PowerShell: > Get-ChildItem "C:\Program Files\WindowsApps" -Directory | > Where-Object Name -like "OpenAI.Codex_" | > Sort-Object LastWriteTime -Descending | > Select-Object -First 1 FullName > Then inspect its resources folder: > > Get-ChildItem "C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources" | > Where-Object Name -in "codex","codex.exe","rg","rg.exe" | > Select-Object Name,FullName > If WSL mode is broken and only codex.exe / rg.exe exist, that matches this issue. > > ### 2. Make sure WSL helper binaries exist > In WSL: > > ls -l /mnt/c/Users/$USER/.codex/bin/wsl/codex /mnt/c/Users/$USER/.codex/bin/wsl/rg > /mnt/c/Users/$USER/.codex/bin/wsl/codex --version > If those files do not exist, copy known-good Linux codex and rg binaries there from a working install/package, then: > > chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex > chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/rg > ### 3. Create a WSL wrapper > Create this file: > > > > > > > > > > > C:\Users<WindowsUser>.codex\bin\wsl\codex-desktop-wsl > `` > > Contents: > > #!/usr/bin/env sh > unset CODEX_HOME > exec /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex "$@" > Then from WSL: > > chmod +x /mnt/c/Users/<WindowsUser>/.codex/bin/wsl/codex-desktop-wsl > The important part is unset CODEX_HOME. It prevents Desktop’s Windows Codex home from leaking into the Linux app-server process. > > ### 4. Point Desktop at the wrapper > In PowerShell: > > [Environment]::SetEnvironmentVariable( > 'CODEX_CLI_PATH', > 'C:\Users\<WindowsUser>\.codex\bin\wsl\codex-desktop-wsl', > 'User' > ) > Then fully restart Codex Desktop. > > ### 5. Verify Desktop is launching WSL correctly > After restart, check the Desktop process command line from PowerShell: > > Get-CimInstance Win32_Process | > Where-Object { $_.CommandLine -match 'codex.*app-server|wsl.exe' } | > Select-Object ProcessId,CommandLine > The good shape is: > ` > > > > > > > > > > > > wsl.exe ... exec /mnt/c/Users//.codex/bin/wsl/codex-desktop-wsl app-server ... > ` > > The bad shape is: > ` > > > > > > > > > > > > exec /mnt/c/Users//AppData/Local/OpenAI/Codex/bin/.../codex.exe app-server > ` > > If you see codex.exe inside the WSL launch command, it is still using the Windows binary. > > ### 6. Re-select WSL in Desktop settings > Open Codex Desktop settings and set the agent runtime back to WSL. > > Then restart the app again. The setting may temporarily revert to Windows after the failed startup, so this final restart matters. > > ## Rollback > To remove the override later: > > [Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $null, 'User') > Only do this after an upstream Desktop update restores proper WSL helper binaries in the app resources. > ` I hit the same WSL startup failure on Windows with Codex Desktop 26.609.4994.0. One thing that tripped me up: I had previously set this in config.toml so the app could start again: runCodexInWindowsSubsystemForLinux = false That is only a recovery step to get Desktop unstuck in Windows mode. Before testing the WSL repair, it has to be set back to: runCodexInWindowsSubsystemForLinux = true or Desktop will try to spawn the WSL wrapper as a Windows executable and fail. The other issue was line endings in my wrapper. With CRLF endings I got: ` code 127 signal null /usr/bin/env: 'sh\r': No such file or directory ` The working wrapper was: ` #!/usr/bin/env sh unset CODEX_HOME exec /mnt/c/Users/<user>/.codex/bin/wsl/codex "$@" ` saved with Unix LF endings at: ` C:\Users\<user>\.codex\bin\wsl\codex-desktop-wsl ` And my Windows user env var was: ` [Environment]::SetEnvironmentVariable( 'CODEX_CLI_PATH', 'C:\Users\<user>\.codex\bin\wsl\codex-desktop-wsl', 'User' ) `` So the full working state was: WSL mode enabled again in config.toml, CODEX_CLI_PATH pointing at the wrapper, and the wrapper saved with LF endings.

thx for expanding on the solution!

Hi, I encountered the same issue and found a workaround that resolved it in my case.
Codex Desktop had been installed on a non-system drive through the Microsoft Store. After uninstalling it and reinstalling the same version on the default system drive (C:), WSL mode started working normally. I did not need to reinstall Codex inside WSL or configure CODEX_CLI_PATH.
This may be caused by Codex Desktop not correctly handling the application path when the MSIX package is installed on a non-system drive.
I hope this is helpful. Please let me know whether reinstalling it on C: works for you as well—or whether the issue still persists afterward.
https://github.com/openai/codex/issues/30094#issue-4746174057

Additional Windows 11 Pro / unified-desktop corroboration:

After the July 2026 unified ChatGPT Work / Codex rollout, one affected installation entered a split state where ChatGPT Classic remained usable but the unified Codex task path exited with code 127 because the generated Windows/WSL launcher path pointed to a missing versioned executable under .codex/bin/wsl/codex.

The important operational distinction was:

• the account and general ChatGPT surface were still usable;
• the WSL-backed Codex workspace failed before task execution;
• the launcher/config state looked present, but the referenced binary target was absent;
• the failure presented as a workspace/config problem rather than an update/migration integrity failure.

This suggests the update path should transactionally verify the WSL launcher target before switching the active desktop environment. If the new target is missing, the app should retain the last working launcher, show the exact missing target and installed versions, and offer an automatic repair/rollback rather than entering code 127.

Private paths and repository names are omitted. A timestamped incident packet and local diagnostic were preserved.

Installing Codex on the system drive and then solve it