[Windows][WSL] Codex Desktop 26.727 becomes unusable after enabling WSL agent — packaged Linux binary returns Permission denied

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

Version 26.727.51351

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After changing the Codex Desktop agent environment from Windows native to WSL and restarting the application, Codex failed to initialize its WSL-side app-server. The app repeatedly displayed a handshake/startup failure and became unusable.

I did not preserve the exact wording of the message. During subsequent diagnostics, however, the Codex executable bundled with the Windows app returned the following error when accessed from Ubuntu:

bash: /mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0/app/resources/codex: Permission denied

A clean Ubuntu login shell also reported:

bash: type: codex: not found

Restarting Codex did not automatically return it to the Windows-native agent. Because the app could not start normally, I could not reopen Settings to disable WSL mode. I eventually recovered the application by using PowerShell to locate the Codex TOML configuration and manually changing the WSL-native agent option back to false.

The main problem is not only that WSL mode failed, but that the failure left the entire desktop application inaccessible without an undocumented manual recovery procedure.

What steps can reproduce the bug?

1. Install and initialize Ubuntu using WSL2.

1. Update Ubuntu and WSL, then confirm that Ubuntu starts normally.

1. Run wsl --status and wsl --list --verbose in PowerShell. Confirm that Ubuntu is the default distribution and is using WSL version 2.

1. Open Codex Desktop on Windows.

1. Open Settings and change the agent environment from Windows native to WSL native.

1. Restart Codex Desktop when prompted.

1. Codex fails to start its WSL-side app-server and repeatedly displays a handshake or startup error.

1. Restarting or reloading Codex does not resolve the problem because the WSL-native setting remains enabled.

1. Since the application cannot start normally, use PowerShell to locate the Codex TOML configuration and manually change the WSL-native setting back to false.

I have not repeated the final mode-switch test because it locks me out of Codex and requires another manual configuration recovery.

What is the expected behavior?

After selecting WSL native as the agent environment and restarting Codex Desktop, the application should start its agent and app-server inside the configured WSL2 distribution.

If the WSL agent cannot start, Codex should clearly display the underlying error and provide a button to return to the Windows-native agent. It should also automatically fall back to Windows-native mode after repeated startup failures.

Codex should verify that the required Linux executable can run before permanently saving the WSL-native setting. A failed WSL startup should not make the entire application inaccessible or require the user to locate and manually edit a configuration file.

Additional information

Codex Desktop runtime version: 26.727.51351

Installed application package directory: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0

Windows version: 10.0.26200.8973, x64

WSL version: 2.7.11.0

WSL kernel: 6.18.33.2-2

Linux distribution: Ubuntu 26.04 LTS, x86_64

Ubuntu systemd status: running

WSL and Ubuntu passed their normal health checks. Ubuntu started correctly, Linux commands worked, and Ubuntu was registered as a WSL version 2 distribution.

After the failed Codex startup, a partial .codex directory existed inside the Ubuntu home directory. It contained SQLite database files, but the WSL-side log database contained no log entries. There was also no native Codex executable under the Ubuntu user’s .local/bin directory.

This suggests that the Codex WSL setup started far enough to create its data directory, but the Linux app-server executable never successfully launched.

The packaged Codex executable under the protected WindowsApps directory returned Permission denied when accessed from Ubuntu. My suspicion is that Codex Desktop is attempting to execute its Linux agent directly from the WindowsApps package directory. Since the executable cannot start, the desktop application cannot complete its handshake with the WSL app-server.

It would be helpful if Codex copied the Linux executable to a user-accessible location before launching it, tested the executable before enabling WSL mode permanently, and provided an automatic recovery option when startup fails.

Possibly related reports:

https://github.com/openai/codex/issues/13699

https://github.com/openai/codex/issues/14700

https://github.com/openai/codex/issues/28086

https://github.com/openai/codex/issues/24884

No WindowsApps permissions, ownership settings, authentication files, or credentials were modified during diagnosis. Personal usernames and project paths have been redacted.