Codex is looking for bwrap in wrong place

[bromdun]

What version of the Codex App are you using (From “About Codex” dialog)?

0.116.0 CLI

What subscription do you have?

Pro

What platform is your computer?

Ubuntu

What issue are you seeing?

I have the bubblewrap installed, but I'm unable to install it to the location that Codex is looking for it at. So I still get this error: ⚠ 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.

The issue is that Codex is looking specifically at /usr/bin/bwrap, but since bubblewrap was installed via Nix, the binary lives in the Nix store — not in /usr/bin. Both /usr/bin and /usr/local/bin are read-only in this environment, so we can't place a symlink there for Codex to find.

And it seems there are permission issues related to using the vendor bubblewrap because I'm unable to do code reviews using /review. Everything works in 0.114.0. But I have lots of bwrap related problems with 0.115.0, which was unusable. And still in 0.116.0, I have these problems, though it seems to run better than the previous version. I've had to go back to using 0.114.0.

What steps can reproduce the bug?

Just have bubblewrap installed in a location different than where Codex is looking for.

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Suppress the warning ⚠ Codex could not find system bubblewrap at /usr/bin/bwrap when sandbox is bypassed. #15282
• VS Code extension bundled Codex 0.116 fails on Rocky 8 with bwrap: Unknown option --argv0 #15291

Powered by Codex Action

[frangio]

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

[coreyt]

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.

[CHENyiru3]

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

[zeldrisho]

I use Homebrew on Linux and had the same problem

[bromdun]

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.

[CHENyiru3]

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

[rollingferret]

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.