Codex Desktop WSL sandbox cannot find system bwrap; legacy Landlock fallback panics with permission profiles

Open 💬 1 comment Opened May 28, 2026 by ellery97

What version of Codex is running?

codex-cli 0.133.0

This is happening from the Codex Desktop app, with the WSL Codex binary located under the desktop cache path:

/mnt/c/Users/<WindowsUser>/.codex/bin/wsl/<hash>/codex

What platform is your computer?

Windows host with WSL2 Ubuntu:

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.6 LTS
Release:	20.04
Codename:	focal

Kernel:

Linux <host> 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

What issue are you seeing?

Sandboxed tool execution fails before the target command runs. A minimal command such as pwd fails in the Codex sandbox with:

thread 'main' (...) panicked at linux-sandbox/src/launcher.rs:43:13:
bubblewrap is unavailable: no system bwrap was found on PATH and no bundled codex-resources/bwrap binary was found next to the Codex executable
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This also breaks other local filesystem helpers that go through the sandbox, for example reading a local image file from the WSL-mounted Windows filesystem.

The issue occurs even though system bubblewrap is installed, discoverable, executable, and works when tested outside the failing Codex sandbox:

$ which bwrap
/usr/bin/bwrap

$ bwrap --version
bubblewrap 0.4.0

$ bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp /bin/true
# exits 0

The Codex binary directory does not contain a bundled bwrap resource. After checking the adjacent resource directory, no bundled bwrap is present:

/mnt/c/Users/<WindowsUser>/.codex/bin/wsl/<hash>/codex-resources
# empty / no bwrap present

Legacy Landlock workaround also fails

As a workaround, I tried enabling the feature flag:

[features]
use_legacy_landlock = true

After that, the original bwrap lookup panic changes into a different panic:

thread 'main' (...) panicked at linux-sandbox/src/linux_run_main.rs:311:9:
permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This happens for both a minimal shell command (pwd) and local image reading through the app's filesystem sandbox helper.

Steps to reproduce

  1. Use Codex Desktop with a WSL2 Ubuntu 20.04 workspace.
  2. Ensure system bubblewrap is installed and works:
which bwrap
bwrap --version
bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp /bin/true
  1. Start a Codex Desktop session with normal workspace sandboxing enabled.
  2. Ask Codex to run a trivial command such as pwd.
  3. Observe that the command fails before execution with the bubblewrap is unavailable panic.
  4. Enable use_legacy_landlock = true.
  5. Retry the same command.
  6. Observe the permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock panic.

Expected behavior

Codex should either:

  • discover and use the system /usr/bin/bwrap available in the WSL environment,
  • ship/use a valid bundled codex-resources/bwrap next to the WSL Codex binary, or
  • provide a supported configuration path for Codex Desktop/WSL users to point the sandbox launcher at the system bwrap.

If use_legacy_landlock is no longer compatible with the permission profiles used by Codex Desktop, the app should document that limitation and avoid recommending it as a fallback for this environment.

Related issues

This looks very close to #21915, but that report was for the VS Code extension / remote environment and codex-cli 0.130.0-alpha.5. This report is for Codex Desktop WSL with codex-cli 0.133.0 and additionally confirms that use_legacy_landlock now fails with the permission-profile panic.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗