v0.116.0 ubuntu22.04 errors mentioning bwrap sandbox wrapper constantly occur

Resolved 💬 8 comments Opened Mar 20, 2026 by jacob-a6 Closed Mar 20, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.116..0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.8.0-94-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Terminal

What issue are you seeing?

Pretty much any prompt runs into a sandbox error which mentions bwrap e.g.

codex gpt 5.4 high chain of thought says

✘ Failed to apply patch
  └ bwrap: Unknown option --argv0
• apply_patch is blocked by the same broken sandbox wrapper, so I’m resolving
  the conflict with non-interactive git/perl commands outside the sandbox to
  keep the cherry-pick moving without touching unrelated lines.

What steps can reproduce the bug?

Any prompt will reproduce the bug on 0.116..0

What is the expected behavior?

_No response_

Additional information

Downgrading to v0.115.0 is a workaround to avoid the issue. v0.115.0 was working fine.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 4 months ago

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

#15057
#14919

Powered by Codex Action

jacob-a6 · 4 months ago

Perhaps this is related https://github.com/openai/codex/pull/14963

BlueWater86 · 4 months ago

Perhaps this is related #14963

That looks like a plausible related regression.

I am on Debian 12 and have the same problem. Bubblewrap is at 0.8.0 on my system and apt candidate is also 0.8.0-2+deb12ul, so there is no newer distro upgrade path to a newer bwrap that acepts --argv0.

I attempted a user-level PATH wrapper for bwrap but that did not help, suggesting that the harness is calling /usr/bin/bwrap directly rather than resolving through PATH.

XIUANGH · 4 months ago

> Perhaps this is related #14963 That looks like a plausible related regression. I am on Debian 12 and have the same problem. Bubblewrap is at 0.8.0 on my system and apt candidate is also 0.8.0-2+deb12ul, so there is no newer distro upgrade path to a newer bwrap that acepts --argv0. I attempted a user-level PATH wrapper for bwrap but that did not help, suggesting that the harness is calling /usr/bin/bwrap directly rather than resolving through PATH.

Everything is explained in this link codex-linux-sandbox, and it prioritizes /usr/bin/bwrap.

BlueWater86 · 4 months ago

> > Perhaps this is related #14963 > > > That looks like a plausible related regression. > I am on Debian 12 and have the same problem. Bubblewrap is at 0.8.0 on my system and apt candidate is also 0.8.0-2+deb12ul, so there is no newer distro upgrade path to a newer bwrap that acepts --argv0. > I attempted a user-level PATH wrapper for bwrap but that did not help, suggesting that the harness is calling /usr/bin/bwrap directly rather than resolving through PATH. Everything is explained in this link codex-linux-sandbox, and it prioritizes /usr/bin/bwrap.

I understand that codex-linux-sandbox prioritizes /usr/bin/bwrap. That seems consistent with what I observed, and it is exactly why this fails on Debian 12 in my case. The problem is that /usr/bin/bwrap is 0.8.0 here, and that version does not support --argv0. Since the current Debian 12 candidate is also 0.8.0-2+deb12u1, there is no normal distro upgrade path to a compatible system bwrap. So the practical issue is not whether /usr/bin/bwrap is preferred, but that the runner appears to assume a newer system bwrap interface than this distro provides.

XIUANGH · 4 months ago

> > > Perhaps this is related #14963 > > > > > > That looks like a plausible related regression. > > I am on Debian 12 and have the same problem. Bubblewrap is at 0.8.0 on my system and apt candidate is also 0.8.0-2+deb12ul, so there is no newer distro upgrade path to a newer bwrap that acepts --argv0. > > I attempted a user-level PATH wrapper for bwrap but that did not help, suggesting that the harness is calling /usr/bin/bwrap directly rather than resolving through PATH. > > > Everything is explained in this link codex-linux-sandbox, and it prioritizes /usr/bin/bwrap. I understand that codex-linux-sandbox prioritizes /usr/bin/bwrap. That seems consistent with what I observed, and it is exactly why this fails on Debian 12 in my case. The problem is that /usr/bin/bwrap is 0.8.0 here, and that version does not support --argv0. Since the current Debian 12 candidate is also 0.8.0-2+deb12u1, there is no normal distro upgrade path to a compatible system bwrap. So the practical issue is not whether /usr/bin/bwrap is preferred, but that the runner appears to assume a newer system bwrap interface than this distro provides.

I also think this change is frustrating. It might be necessary to compile and install a new version of bwrap manually, but this also carries risks. In short, this may need to be handled by Codex.

BlueWater86 · 4 months ago

also think this change is frustrating. It might be necessary to compile and install a new version of bwrap manually, but this also carries risks. In short, this may need to be handled by Codex.

This should be handled by Codex, since there is currently no user-facing way to influence the new default behavior introduced by the related PR and there is no normal distro upgrade path to a newer compatible version. I share your belief of the risk, requiring users to manually build and replace a core sandbox binary is not a reasonable expectation for an extension update.

lukestanley · 4 months ago

@etraut-openai even if the cause is related, v0.116 repeatedly prompts for escalation on same file despite "don't ask again" does not sound like a duplicate of v0.116.0 ubuntu22.04 errors mentioning bwrap sandbox wrapper constantly occur.
(I just had to downgrade Codex CLI version too.)