bwrap: Failed RTM_NEWADDR: Operation not permitted

[udayshnk]

Description

After updating Codex CLI to 0.115.0, the Linux bubblewrap sandbox fails with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

This worked fine before the update. Subagents cannot execute any commands in sandbox mode.

Environment

• OS: Ubuntu 24.04.4 LTS (Noble Numbat)
• Kernel: 6.17.0-19-generic
• Codex version: 0.115.0
• bwrap version: 0.9.0
• bwrap binary: /usr/bin/bwrap (not setuid)

Thread

Uploaded thread: 019cfb76-f176-71d2-b80e-b03ab6bc6a38

[github-actions]

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

• VS Code Codex extension sandbox makes writable devcontainer workspace appear read-only in Linux #14794
• Bubblewrap regression on Linux/WSL: missing writable_roots fail command startup and detached children are reaped #14875

Powered by Codex Action

[udayshnk]

After reviewing the flagged duplicates, this is not a duplicate:

• VS Code Codex extension sandbox makes writable devcontainer workspace appear read-only in Linux #14794 is about VS Code extension sandbox write permissions inside a devcontainer
• Bubblewrap regression on Linux/WSL: missing writable_roots fail command startup and detached children are reaped #14875 is about missing writable_roots and detached child process regressions on WSL

This issue is specifically about bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted on bare Ubuntu 24.04 (no Docker, no WSL, no devcontainer) due to AppArmor restricting unprivileged user namespaces (kernel.apparmor_restrict_unprivileged_userns=1), which is enabled by default on Ubuntu 24.04. The regression started with the 0.115.0 update.

[reflexator]

same problem on Ubuntu 24.04.3, codex-cli 0.115.0

worked just fine before update

[ignatremizov]

+1

[rogerflowey]

rollback to 0.114.0 can temporarily fix it

[viyatb-oai]

can you try setting

sudo sysctl -w kernel.unprivileged_userns_clone=1
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Ubuntu 24+ ships with a restrictive AppArmor policy that restricts bubblewrap from working correctly.

[ghztomash]

Exact same error here, downgrading to 0.114.0 solves the problem

[joliss]

@viyatb-oai Yes, that fixes it on Ubuntu 25.10. The second line alone (sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0) is enough.

[ghztomash]

Removing a system wide mitigation against kernel privilege escalation exploits does not sound like a fix to me...

Possibly better approach is to create an AppArmor profile to allow userns for codex, though how was it working before?

[filimonov]

+1. It's related to #13996

Workaround (to still use old sandbox):

codex --enable use_legacy_landlock
codex features enable use_legacy_landlock

Some details:

Started to happen after upgrading to codex-cli 0.115.0.
Exceptions like bwrap: setting up uid map: Permission denied and similar.

Environment:

• Ubuntu 25.04
• kernel 6.14.0-37-generic
• uidmap installed
• kernel.unprivileged_userns_clone = 1
• kernel.apparmor_restrict_unprivileged_userns = 1
• kernel.apparmor_restrict_unprivileged_unconfined = 1

Observed behavior:

• after 0.115.0, normal sandboxed Codex commands fail on this host
• current failure from the default Linux sandbox path is:
  bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
• codex --enable use_legacy_landlock sandbox linux /bin/true works
• system bwrap works:
  /usr/bin/bwrap --ro-bind / / --dev-bind /dev /dev --proc /proc --unshare-user --uid 0 --gid 0 true
• but a copied/non-system bwrap binary fails with the same kind of permission error

This looks like an Ubuntu AppArmor interaction with the 0.115.0 switch to vendored/default bubblewrap.

Ubuntu ships /etc/apparmor.d/bwrap-userns-restrict, which grants userns access specifically to /usr/bin/bwrap. Since Codex now uses a vendored/internal bwrap path, that path is not covered by the Ubuntu AppArmor exception, so the sandbox cannot complete namespace setup on this host.

So this seems to be:

• not a general kernel/userns problem
• not fixed just by installing uidmap
• specifically a problem with the vendored bwrap path on AppArmor-restricted Ubuntu systems

A good fix would be one of:

1. prefer system /usr/bin/bwrap on Linux/AppArmor systems
2. expose a config/env override for the bwrap path
3. document the required AppArmor profile for the vendored sandbox helper