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

[jacob-a6]

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.

[github-actions]

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

• Linux sandbox fails on Ubuntu with AppArmor userns restrictions: bwrap loopback RTM_NEWADDR EPERM #15057
• bwrap: Failed RTM_NEWADDR: Operation not permitted #14919

Powered by Codex Action

[jacob-a6]

Perhaps this is related #14963

[BlueWater86]

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]

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]

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]

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]

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]

@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.)