Codex Desktop WSL sandbox cannot find system bwrap; legacy Landlock fallback panics with permission profiles
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
- Use Codex Desktop with a WSL2 Ubuntu 20.04 workspace.
- Ensure system bubblewrap is installed and works:
which bwrap
bwrap --version
bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp /bin/true
- Start a Codex Desktop session with normal workspace sandboxing enabled.
- Ask Codex to run a trivial command such as
pwd. - Observe that the command fails before execution with the
bubblewrap is unavailablepanic. - Enable
use_legacy_landlock = true. - Retry the same command.
- Observe the
permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlockpanic.
Expected behavior
Codex should either:
- discover and use the system
/usr/bin/bwrapavailable in the WSL environment, - ship/use a valid bundled
codex-resources/bwrapnext 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.
Showing cached comments. Read the full discussion on GitHub ↗
2 Comments
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.Independent reproduction on 2026-07-21.
Environment:
WSLwsl -l -v:Ubuntu-20.04, WSL2, running, and marked as the defaultOutside the managed sandbox (using an explicitly approved escalated diagnostic), the environment is healthy:
The workspace also reports writable outside the failing managed sandbox.
The same diagnostic through normal
workspace-writeexecution fails before the command starts:The failure also prevents
apply_patchfrom 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 --shutdownfollowed by restarting Codex Desktop did not resolve the issue.Current workaround: explicitly approved execution outside the sandbox can see
/usr/bin/bwrapand run commands, but this defeats the normal managed workflow and does not provide a usable fallback forapply_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/bwrapfallback. Logging the launcher's effectivePATHand checked candidate paths would make this substantially easier to diagnose.