Request for safe workaround or recovery path for Codex Desktop 26.609.4994.0 WSL-mode startup failure

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

Codex Desktop 26.609.4994.0 — confirmed via PowerShell as OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0 because the app cannot open the About dialog in WSL mode.

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I am opening this issue to request a safe and reversible workaround or recovery path from the community and maintainers.

This appears related to #27979 and #28103. My issue started immediately after updating Codex Desktop to 26.609.4994.0. Since then, I have not been able to open Codex Desktop in WSL mode.

When launching Codex Desktop in WSL mode, 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.

Codex CLI itself still works from PowerShell:

codex --version

Output:

codex-cli 0.139.0

PowerShell finds Codex here:

where.exe codex

Output:

C:\Program Files\nodejs\codex
C:\Program Files\nodejs\codex.cmd

I also confirmed that CODEX_CLI_PATH has been removed from the user environment:

reg query HKCU\Environment /V CODEX_CLI_PATH

Output:

ERROR: The system was unable to find the specified registry key or value.

WSL shell behavior:

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

Output:

/mnt/c/Program Files/nodejs/codex

However, a login shell finds the WSL-installed 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

I previously tried setting CODEX_CLI_PATH to Windows Node/npm paths such as:

C:\Program Files\nodejs\codex.cmd

That did not resolve the issue. In one attempt, the app appeared to run the Windows .cmd file through a WSL/Linux context, causing a shell syntax error. I have since removed CODEX_CLI_PATH completely and left the environment in a clean state.

Given the findings in #28103 about the missing Linux app/resources/codex binary in the MSIX package, I am looking for guidance on a safe recovery path for users who need WSL mode.

It would be helpful to have community or maintainer confirmation on the safest temporary approach, including:

• leaving CODEX_CLI_PATH unset and waiting for a fixed Codex Desktop update;
• temporarily setting CODEX_CLI_PATH to an existing cached WSL binary under %USERPROFILE%\.codex\bin\wsl\<hash>\codex;
• removing CODEX_CLI_PATH after the next Codex Desktop update if that workaround is used;
• disabling WSL mode and using native Windows mode until a fixed build is released.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with WSL mode enabled.
2. Update Codex Desktop to 26.609.4994.0.
3. Launch Codex Desktop.
4. The app fails to start 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 issue started immediately after the update. Before the update, the same WSL setup worked normally.

I have not modified .codex state, edited state_5.sqlite, copied binaries manually, or installed Codex from third-party mirrors.

What is the expected behavior?

Codex Desktop should launch normally in WSL mode.

For affected users, there should also be a safe and documented recovery path that does not require guessing which cached binary to use, manually modifying .codex state, editing SQLite files, or installing from third-party mirrors.

Additional information

This issue is not intended as a duplicate root-cause report. It is intended to clarify the safest practical workaround while this regression is being investigated.

I would prefer not to modify .codex state, edit state_5.sqlite, copy binaries manually, pin CODEX_CLI_PATH to a cached CLI, or install from third-party mirrors unless the Codex team or experienced users can confirm that the workaround is safe and reversible.

Maintainer or community guidance on the recommended temporary recovery path would be appreciated.