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

Open 💬 3 comments 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 openai/codex#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 ↗

2 Comments

JoshKasap · 3 months ago

I hit a similar Codex Desktop + WSL sandbox issue, but mine started as a bundled bwrap integrity mismatch.

Initial sandboxed commands failed with:

bundled bubblewrap digest mismatch for .../.codex/bin/wsl/codex-resources/bwrap
expected sha256:90604f...
got sha256:067a128...
I confirmed both bundled bwrap copies had the unexpected 067a128... hash. After quarantining/renaming those bad bwrap files, the error changed to:

bubblewrap is unavailable: no system bwrap was found on PATH and no bundled codex-resources/bwrap binary was found next to the Codex executable
Restarting Codex and later doing a full reinstall regenerated the WSL codex and rg binaries, but did not recreate codex-resources/bwrap. Searching the Codex/AppData cache found no valid bundled bwrap.

Final fix was installing system bubblewrap inside WSL:

sudo apt-get update
sudo apt-get install bubblewrap
After that:

command -v bwrap
/usr/bin/bwrap

bwrap --version
bubblewrap 0.9.0
Sandboxed Codex commands started working again. So in my case, Codex Desktop still failed to restore the bundled helper, but installing system /usr/bin/bwrap resolved the issue.

it seems like the desired solution is that .../.codex/bin/wsl/codex-resources/ should probably get regenerated when wsl is removed and regenerated.

pipa83165 · 1 month ago

Independent reproduction on 2026-07-21.

Environment:

  • Windows host running Codex Desktop
  • Agent environment configured as generic WSL
  • Default WSL distribution confirmed with wsl -l -v: Ubuntu-20.04, WSL2, running, and marked as the default
  • Workspace located on the WSL-mounted Windows filesystem

Outside the managed sandbox (using an explicitly approved escalated diagnostic), the environment is healthy:

$ command -v bwrap
/usr/bin/bwrap

$ bwrap --version
bubblewrap 0.4.0

The workspace also reports writable outside the failing managed sandbox.

The same diagnostic through normal workspace-write execution fails before the command starts:

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

The failure also prevents apply_patch from creating files in the configured writable workspace. Extra filesystem permission grants do not help because the failure occurs during sandbox launcher initialization, before the requested command or edit runs. wsl --shutdown followed by restarting Codex Desktop did not resolve the issue.

Current workaround: explicitly approved execution outside the sandbox can see /usr/bin/bwrap and run commands, but this defeats the normal managed workflow and does not provide a usable fallback for apply_patch.

This supports the original report's diagnosis: the Codex Desktop WSL sandbox launcher is using a binary-discovery environment that differs from the WSL shell environment, or the Desktop WSL bundle is missing the adjacent codex-resources/bwrap fallback. Logging the launcher's effective PATH and checked candidate paths would make this substantially easier to diagnose.

Showing cached comments. Read the full discussion on GitHub ↗