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!