Skip to content

WSL integration broken even with fresh installs #28074

Open
Open
WSL integration broken even with fresh installs#28074
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

Description

@grezniczek
grezniczek
opened on Jun 13, 2026

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

26.609.41114

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

  • Totally fresh install of Codex App (after uninstall and removal of .codex folders both on Win and WSL).
  • Switch from Windows native to WSL via Settings
  • Restart app.
  • CODEX_CLI_PATH error
Image

Trying stuff like pointing CODEX_CLI_PATH to codex cli in WSL - no luck.

Only way back from there is manually editing config.toml to have

runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

Working through wsl.exe is a no go, because each and every write will ask for approval.

What steps can reproduce the bug?

  • Remove Codex App and all .codex folders
  • Install fresh
  • Switch to WSL in Settings
  • Restart app
  • Get error (see above)

What is the expected behavior?

Switching to WSL works.

Additional information

Please test releases better before actually releasing them. I appreciate the speed of iterations, but loosing half a day over this is not fun. Thanks.

Activity

  1. grezniczek
    added
    appIssues related to the Codex desktop app
    on Jun 13, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 13, 2026

  3. github-actions commented on Jun 13, 2026

    @github-actions
    github-actionsbot
    on Jun 13, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. jakubsadel commented on Jun 13, 2026

    @jakubsadel
    jakubsadel
    on Jun 13, 2026

    I have same problem, is there any solution?

  5. andreidita22 commented on Jun 13, 2026

    @andreidita22
    andreidita22
    on Jun 13, 2026

    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.

  6. AnhLead commented on Jun 13, 2026

    @AnhLead
    AnhLead
    on Jun 13, 2026

    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

  7. mosesadewale commented on Jun 14, 2026

    @mosesadewale
    mosesadewale
    on Jun 14, 2026

    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.

  8. grezniczek commented on Jun 14, 2026

    @grezniczek
    grezniczek
    on Jun 14, 2026
    Author

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

  9. davidjirovec commented on Jun 15, 2026

    @davidjirovec
    davidjirovec
    on Jun 15, 2026

    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.

  10. linuxdropout commented on Jun 15, 2026

    @linuxdropout
    linuxdropout
    on Jun 15, 2026
    Image

    Still broken for me too

  11. andreidita22 commented on Jun 15, 2026

    @andreidita22
    andreidita22
    on Jun 15, 2026

    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//.codex/bin/wsl/codex
    chmod +x /mnt/c/Users//.codex/bin/wsl/rg

    3. Create a WSL wrapper

    Create this file:

    C:\Users.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!

  12. wangchenxudev commented on Jul 23, 2026

    @wangchenxudev
    wangchenxudev
    on Jul 23, 2026

    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.
    #30094 (comment)

  13. grtninja commented on Jul 23, 2026

    @grtninja
    grtninja
    on Jul 23, 2026 – with ChatGPT Codex Connector

    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.

  14. LyonWu21 commented on Aug 19, 2026

    @LyonWu21
    LyonWu21
    on Aug 19, 2026

    Installing Codex on the system drive and then solve it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions