Codex is looking for bwrap in wrong place

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #15282
• #15291

Powered by Codex Action

Yes, system bwrap should be looked up in $PATH, not assumed to be in /usr/bin/bwrap.

Confirmed root cause + Ubuntu 20.04 workaround

Investigated this on Ubuntu 20.04.6 LTS aarch64. A few findings that might help clarify the issue and help people on Ubuntu 20.04 specifically.

Hardcoded path confirmed via strings

Codex does not use $PATH to locate bwrap — the path /usr/bin/bwrap is hardcoded in the native binary. This explains why placing a newer bwrap at /usr/local/bin/bwrap, prepending PATH, or setting BWRAP= / BUBBLEWRAP= environment variables has no effect, as several people have noted in #15291 and #15283.

Why the embedded fallback doesn't help on Ubuntu 20.04

Codex ships a vendored bwrap and falls back to it only when no system bwrap is found at /usr/bin/bwrap. A present-but-broken /usr/bin/bwrap (e.g. Ubuntu 20.04's 0.4.0) blocks the fallback entirely. You get the worst of both worlds: the system bwrap is too old to work, and the bundled one is never used.

Workaround for Ubuntu 20.04 (requires root)

Since Ubuntu 20.04 focal won't receive a bwrap backport and apt upgrade is a dead end, the only reliable fix is to build a newer bwrap from source and install it to /usr/bin/bwrap. The dpkg-divert step is important — without it, any apt upgrade or apt install bubblewrap will silently overwrite your newer binary with 0.4.0 again.

# Install build deps
sudo apt-get install -y ninja-build libcap-dev pkg-config gcc meson

# Build bwrap 0.11.0
wget https://github.com/containers/bubblewrap/releases/download/v0.11.0/bubblewrap-0.11.0.tar.xz
# verify SHA256: 988fd6b232dafa04b8b8198723efeaccdb3c6aa9c1c7936219d5791a8b7a8646
tar xf bubblewrap-0.11.0.tar.xz && cd bubblewrap-0.11.0
meson setup _build --prefix=/usr --bindir=. -Dman=disabled -Dtests=false
ninja -C _build

# Divert the old binary so apt can't overwrite the new one
sudo dpkg-divert --local --divert /usr/bin/bwrap.distrib --rename /usr/bin/bwrap
sudo install -m 755 _build/bwrap /usr/bin/bwrap

# Verify
bwrap --version              # bubblewrap 0.11.0
codex sandbox linux /usr/bin/echo "hello world!"  # hello world!

To revert:

sudo rm /usr/bin/bwrap
sudo dpkg-divert --remove --rename /usr/bin/bwrap

Tested on Ubuntu 20.04.6 aarch64, Codex 0.116.0. Also works on x86_64 focal.

This happened after updating codex. Is this specifically causing by codex after a version? I may try to downgrade codex

I use Homebrew on Linux and had the same problem

This happened after updating codex. Is this specifically causing by codex after a version? I may try to downgrade codex

114 works fine for me. Problems started at 115 and continue with 116.

> This happened after updating codex. Is this specifically causing by codex after a version? I may try to downgrade codex 114 works fine for me. Problems started at 115 and continue with 116.

Yes, I forgot to update my progress! In fact I am using version 0.114.0 now and works well lol. Anyone with the same problem could try this:

npm install -g @openai/codex@0.114.0

This also means that, Codex newest version is not stable. Hope they can fix bugs soon

Wish I found this before digging deep.

PopOS 22.04 also having this issue due bwrap version 0.6. PATHS don't work. Was about to nuke my bwrap to test if Codex can even do a fall over to it's bwrap.

Can confirm downgrading works. Seems it's related to how they're passing args to bwrap.

Hope they fix this ASAP. We should be allowed to use the builtin bwrap.

/expirmental and /collab also silently fail. I thought the features where broken. Guessing these are using bwrap for the multi agent flow.

Confirming this on NixOS as well.

Environment:

• codex-cli 0.116.0
• nixos-version: 25.11.20260316.48652e9 (Xantusia)
• command -v bwrap: /home/exec/.nix-profile/bin/bwrap

On NixOS, /usr/bin is generally not populated, so looking specifically for /usr/bin/bwrap is not a valid check. bwrap can be installed and available on PATH, but Codex still prints:

⚠ Codex could not find system bubblewrap at /usr/bin/bwrap. Please install bubblewrap with your package manager. Codex will use the vendored bubblewrap in the meantime.

Expected behavior: detect bwrap from PATH (or otherwise avoid assuming /usr/bin/bwrap exists) instead of hard-coding a FHS path.

The bwrap PATH lookup fix merged in #15791 and is available in 0.117.0-alpha.25. If you're installing bwrap outside /usr/bin (for example Nix, Homebrew on Linux, or /usr/local/bin), can you try 0.117.0-alpha.25 or newer and confirm Codex picks it up from PATH?

If it still fails, please share which bwrap and codex --version.

It still fails in 0.117.0-alpha.25.

This version fails to find the system bwrap whenever PATH contains multiple paths.

@frangio can you print out which bwrap and $PATH (redacted, I only need to see bwrap versions)

The bwrap PATH lookup fix merged in #15791 and is available in 0.117.0-alpha.25. If you're installing bwrap outside /usr/bin (for example Nix, Homebrew on Linux, or /usr/local/bin), can you try 0.117.0-alpha.25 or newer and confirm Codex picks it up from PATH? If it still fails, please share which bwrap and codex --version.

After digging further, I think this breaks down into two distinct issues.

First, #15340 is a real system-bwrap discovery bug. In released Codex 0.116.0 and 0.117.0, the Linux sandbox code looks for system bubblewrap at /usr/bin/bwrap, which breaks Nix-based environments like Replit where bwrap is on PATH but not installed under /usr/bin. Upstream has already merged #15791 to switch lookup to PATH, and follow-up #15973 says the first PATH-based implementation still failed on normal multi-entry PATH values and was still reproducing #15340. So “bwrap is installed and visible on PATH, but Codex still says it cannot find it” is a valid Codex bug, not just a Replit quirk. ([GitHub][1])

Second, there is a separate sandbox-backend compatibility problem in Replit. Replit documents Nix-managed workspace packages through replit.nix, which is exactly the kind of setup where a tool is available in the shell without living under /usr/bin. But Codex’s 0.117 Linux sandbox docs also say the default bubblewrap pipeline explicitly uses --unshare-user and --unshare-pid, and bubblewrap’s own man page says the user namespace is required unless bwrap is installed setuid root. In my Replit workspace, running bwrap directly fails with “No permissions to create a new namespace,” so even after PATH discovery is fixed, the default Codex bubblewrap backend still appears incompatible with a standard unprivileged Replit workspace. Open #15893 is adding a clearer warning for exactly this class of failure. ([Replit Docs][2])

So the most accurate conclusion is: #15340 is real, but it is only one layer of the problem. Fixing system-bwrap lookup is necessary, but not sufficient, for Replit. There also appears to be an environment-level incompatibility with Codex’s default non-setuid bubblewrap sandbox. ([GitHub][3])

For historical context, this also matches the regression I saw across versions: 0.115 switched the default filesystem sandbox to bubblewrap while keeping the legacy Landlock fallback available via features.use_legacy_landlock = true or -c use_legacy_landlock=true. That helps explain why 0.114 worked in this environment while 0.115+ started failing. ([GitHub][4])

My request would be to treat these as separate issues:

1. resolve system bwrap from PATH correctly,
2. detect and clearly report namespace-denied environments at startup, and
3. document or auto-suggest the legacy Landlock fallback for restricted container environments like Replit when bubblewrap cannot create the required namespaces. ([GitHub][3])

Codex’s default bubblewrap backend appears incompatible with a standard unprivileged Replit workspace. [Ubuntu Manpages][5])

Environment:

Replit (NixOS-based container)
Codex version: 0.117.0
bwrap --version: bubblewrap 0.8.0 (installed via Nix, available on PATH)

@viyatb-oai Try any PATH variable with multiple paths in it separated by colons. The code isn't getting to the search part because join_paths fails.

@bromdun I'm going to fix the Replit like issue separately