[Solved] Codex Desktop WSL Sandbox Permission Error: Working Fix Using Linux-Native CODEX_HOME

Codex
,
1

Verified Recovery: Codex Desktop WSL Sandbox Permission Error

I am sharing a working recovery method for developers experiencing sandbox execution failures when using Codex Desktop with WSL.

This solution was successfully applied in our development environment and restored normal, non-elevated command execution.

1. Problem Description

When Codex Desktop runs projects inside WSL, ordinary commands such as pwd, ls, or git status may fail before execution.

A typical error is:

Failed to create unified exec process:
No such file or directory (os error 2)

The Linux project directory exists, and commands can work in a normal WSL terminal, but Codex Desktop’s sandbox execution fails.

2. Recovery Approach

The recovery method separates the Codex Desktop WSL helper/runtime environment from the Windows-mounted filesystem.

Instead of using a Windows-backed CODEX_HOME for the WSL helper environment, a dedicated CODEX_HOME is prepared on the native Linux filesystem.

Example environment:

WSL user: vdiuser
Linux home: /home/vdiuser
Dedicated CODEX_HOME: /home/vdiuser/.codex-desktop

3. Step-by-Step Recovery

Step 1: Check the existing environment

Run the following commands in WSL:

whoami
echo "$HOME"
printenv CODEX_HOME

Confirm the actual WSL user and home directory.

Also verify whether normal non-elevated execution from Codex Desktop fails in the actual project directory.

Do not change an environment that is already working correctly.

Step 2: Back up the existing shell profile

cp -a ~/.bash_profile ~/.bash_profile.backup-$(date +%Y%m%d-%H%M%S)

Step 3: Prepare a Linux-native Codex home

mkdir -p "$HOME/.codex-desktop"
chmod 700 "$HOME/.codex-desktop"

Before enabling the new CODEX_HOME, preserve or connect the existing configuration, authentication, and session information required by your installation.

Do not delete existing credentials, configuration files, or session history.

Do not blindly copy temporary helper directories from the failing environment.

Step 4: Modify ~/.bash_profile

Add the following block to the end of the existing .bash_profile:

# Codex Desktop: isolate WSL temporary helpers on the Linux filesystem
if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then
    if [ -d /home/vdiuser/.codex-desktop ]; then
        export CODEX_HOME=/home/vdiuser/.codex-desktop
    fi
fi

Replace /home/vdiuser with the actual WSL user’s home directory if different.

This configuration changes CODEX_HOME only when the session is launched by Codex Desktop.

Normal WSL sessions continue using their existing environment.

4. Why This Works

The configuration isolates Codex Desktop’s WSL helper/runtime files from the Windows-backed filesystem.

The conditional environment variable:

CODEX_INTERNAL_ORIGINATOR_OVERRIDE="Codex Desktop"

ensures that the dedicated Linux-native CODEX_HOME is used only for Codex Desktop WSL sessions.

This reduces interference between Windows-side and Linux-side temporary helper environments.

The recovery was verified locally. The complete upstream root cause has not been independently established by this workaround.

5. Verification

First, check the shell profile syntax:

/bin/bash -n ~/.bash_profile

Completely exit Codex Desktop and restart it.

Then execute the following commands from Codex Desktop using normal, non-elevated WSL execution:

pwd
printenv CODEX_HOME

Expected CODEX_HOME in this example:

/home/vdiuser/.codex-desktop

Verify the following:

  • Normal non-elevated commands execute successfully.

  • The actual WSL project directory is accessible.

  • CODEX_HOME points to the Linux-native directory.

  • Temporary helper/runtime files are created on the Linux filesystem.

  • Existing authentication and configuration remain functional.

  • Existing session history remains available.

  • Sandbox execution works without disabling sandbox security.

6. Recovery Result

In our affected development environment, this conditional CODEX_HOME configuration successfully restored normal WSL sandbox execution.

The existing project files and authentication/session data were preserved.

This is a locally verified workaround, not an official upstream patch.

7. Recommendations

Before applying this workaround:

  1. Confirm that the affected system exhibits the same class of WSL sandbox/helper execution failure.

  2. Verify the actual WSL username and home directory.

  3. Back up the existing shell profile.

  4. Preserve the configuration, authentication, and session data required by Codex.

  5. Apply the conditional CODEX_HOME override only after preparing the dedicated Linux directory.

  6. Verify normal non-elevated execution after restarting Codex Desktop.

If verification fails, stop further changes and restore the backed-up configuration after reviewing the failure.

8. Related GitHub Report

This recovery method has also been documented in the OpenAI Codex GitHub repository.

Issue #40583

Report title:

“Verified recovery: use a Linux-native CODEX_HOME only for Codex Desktop WSL sessions”

9. Discussion and Support

If you experience the same issue or need additional technical details, please reply to this discussion or leave a comment on the related GitHub issue.

I hope this recovery method helps other developers restore their WSL development environments without losing existing settings or sessions.