bwrap: Failed RTM_NEWADDR: Operation not permitted

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

• #14794
• #14875

Powered by Codex Action

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

• #14794 is about VS Code extension sandbox write permissions inside a devcontainer
• #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.

same problem on Ubuntu 24.04.3, codex-cli 0.115.0

worked just fine before update

+1

rollback to 0.114.0 can temporarily fix it

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.

Exact same error here, downgrading to 0.114.0 solves the problem

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

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?

+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

I have an additional data point that seems to narrow the root cause further.

I reproduced the same failure class in an Incus-based jail setup, but the important part is that this does not appear to be Incus-specific. The common factor is whether the actual unprivileged user that Codex runs as is allowed to create the namespaces bubblewrap needs.

What I observed:

• root inside the container can create a user namespace
• the unprivileged agent user cannot
• Codex runs commands as agent
• when that user cannot create the required namespace(s), the normal sandbox path fails

Minimal probes that separated the issue for me:

su - agent -c 'unshare -Ur true'
su - agent -c 'bwrap --unshare-user --uid 0 --gid 0 --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 --proc /proc --dev /dev /bin/true'

In my case these fail for the unprivileged user while the equivalent test as root succeeds.

I also confirmed that the effective blocker was AppArmor’s restriction on unprivileged user namespaces. In the jail setup, setting:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

on the host made the agent-level bwrap test succeed again.

Requests / possible improvements:

1. Add an explicit preflight check for the actual execution user (for example: unshare -Ur true or an equivalent internal probe) and fail with a direct error mentioning AppArmor/unprivileged userns.
2. Document Ubuntu/AppArmor-specific guidance, including the difference between:

• global sysctl relaxation
• targeted AppArmor profile for the Codex binary

I encounter the same issue on my Ubuntu24.04. Works totally fine before that

codex --version 
codex-cli 0.116.0

I'm also experiencing this, I'm currently downgrading to 0.114 as a workaround.

Codex 0.116.0 seems to fix this, provided that you apt-get install bubblewrap.

Without bubblewrap installed, it prints the following warning message when starting, and sandbox commands fail:

⚠ 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.

After installing it with apt-get install bubblewrap, Codex seems to pick up the system Bubblewrap, and the sandbox works again.

Using Ubuntu 24 with codex-cli 0.116.

I'm getting this:

apply_patch(auto_approved=true) exited 1 in 16ms:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
codex
The patch tool hit a sandbox failure on the first write attempt. I’m retrying with a smaller file update; if that still fails, I’ll need to fall back to shell-based edits despite the normal preference for `apply_patch`.
file update...

I have bubblewrap installed.

$ codex --version
codex-cli 0.116.0

$ sudo apt install bubblewrap
[sudo] password for helgiborg:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
bubblewrap is already the newest version (0.9.0-1ubuntu0.1).
bubblewrap set to manually installed.

$ bwrap --version
bubblewrap 0.9.0

Is there any update on this? I still have this issue.

the use_legacy_landlock workaround mentioned above seems to work, but yeah this should probably be addressed somehow

I'm updating the official Codex documentation soon, but you'll need to install Bubblewrap for eg. apt-get install bubblewrap which installs the correct AppArmor policy for Codex to work or have unprivileged user namespaces enabled via sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0.

This should be fixed in 0.117.0.

@etraut-openai

This should be fixed in 0.117.0.

you mean regardless of this (from @viyatb-oai in the msg above)

but you'll need to install Bubblewrap for eg. apt-get install bubblewrap which installs the correct AppArmor policy for Codex to work

?

asking because I work on several remote machines I don't have admin privileges for, so it would spare a lot of pain if that were the case. So for example on one machine I have bwrap v0.9.0, on another v0.6.1, and so on.

For anyone still hitting this on Ubuntu 24.04 with Codex 0.117.0 even though bubblewrap is already installed:

I was still getting sandbox failures, and the decisive check was that the actual unprivileged user could not create the required user namespace:

unshare -Ur true
# unshare: write failed /proc/self/uid_map: Operation not permitted

Inside Codex, /usr/bin/bwrap was already being used:

!command -v bwrap
!readlink -f "$(command -v bwrap)"
# both -> /usr/bin/bwrap

and the relevant sysctls were:

sysctl kernel.apparmor_restrict_unprivileged_userns
# kernel.apparmor_restrict_unprivileged_userns = 1

sysctl kernel.unprivileged_userns_clone
# kernel.unprivileged_userns_clone = 1

Also, a direct Bubblewrap test still failed:

/usr/bin/bwrap --unshare-user --uid 0 --gid 0 \
  --ro-bind /usr /usr --ro-bind /bin /bin \
  --ro-bind /lib /lib --ro-bind /lib64 /lib64 \
  --proc /proc --dev /dev /bin/true
# bwrap: setting up uid map: Permission denied

What fixed it for me was installing Ubuntu’s separate AppArmor profile package and enabling the bwrap-userns-restrict profile:

sudo apt update
sudo apt install apparmor-profiles
sudo cp /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict
sudo systemctl reload apparmor

After that, the direct bwrap test succeeded and Codex started working.

How to verify on your machine as the unprivileged user running codex:

ls -l /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/bwrap-userns-restrict
sudo aa-status | grep bwrap
/usr/bin/bwrap --unshare-user --uid 0 --gid 0 \
  --ro-bind /usr /usr --ro-bind /bin /bin \
  --ro-bind /lib /lib --ro-bind /lib64 /lib64 \
  --proc /proc --dev /dev /bin/true

Background: bwrap-userns-restrict is not part of the base apparmor package on current Ubuntu packaging. Ubuntu ships it in the separate apparmor-profiles package, and the bwrap profile is not enabled by default. So having bubblewrap installed and having /usr/bin/bwrap present is still not sufficient if AppArmor is denying unprivileged user namespaces for bwrap.

One extra detail: after enabling the bwrap profile, unshare -Ur true may still fail, because that profile applies to bwrap, not to the unshare binary in general. For Codex, the important check is the direct /usr/bin/bwrap ... test above.

Follow-up data point from my Ubuntu 24.04 setup: the bwrap-userns-restrict solution fixed Codex for me, but it also broke some Flatpak apps.

After enabling the bwrap AppArmor profile, Codex 0.117.0 started working, but some Flatpak apps started failing on startup or during file updates. The kernel log showed AppArmor denials like these:

journalctl -k -b | grep -E 'profile="bwrap"|profile="unpriv_bwrap"'

I was seeing apparmor="DENIED" with operation="link" under both profile="bwrap" and profile="unpriv_bwrap" for paths inside Flatpak app data directories.

Have a look at:

• Apparmor: New update broke flatpak with apparmor="DENIED"
• Apparmor bwrap-userns-restrict need to be updated
• AppArmor 4.0.2 released : Important Note: AppArmor 4.0.2 does not address interactions between the bwrap_userns_restrict and flatpak profiles. The bwrap profile is not enabled by default, if enabled the flatpak profile needs to be updated.

So in my case there is a real conflict:

• enabling bwrap-userns-restrict fixes Codex
• but the same profile breaks some Flatpak apps

What finally worked for me as a combined setup was:

1. Disable the bwrap AppArmor profile again so Flatpak apps work:

sudo aa-disable /usr/bin/bwrap
sudo systemctl reload apparmor

1. Allow unprivileged user namespaces globally so Codex can use the normal sandbox without the bwrap AppArmor profile:

sudo tee /etc/sysctl.d/60-apparmor-namespace.conf >/dev/null <<'EOF'
kernel.apparmor_restrict_unprivileged_userns=0
EOF
sudo sysctl --system

So my conclusion is: on Ubuntu 24.04, bwrap-userns-restrict can solve the Codex issue, but it can also conflict with Flatpak apps. The workaround that solved both for me was to disable the bwrap AppArmor profile and set kernel.apparmor_restrict_unprivileged_userns=0 persistently.

0.118.0 still get error

So is codex effectively unsupported on Ubuntu 24.04 and later based distributions now?

So is codex effectively unsupported on Ubuntu 24.04 and later based distributions now?

This worked for me on Ubuntu 24.04LTS

I'm updating the official Codex documentation soon, but you'll need to install Bubblewrap for eg. apt-get install bubblewrap which installs the correct AppArmor policy for Codex to work or have unprivileged user namespaces enabled via sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0.

Can you elaborate on which AppAmor policy that is and where it should come from, to help me find it? Because on 24.04 i see no traces of this being the case.

Looking for apparmor profile

% apt-get install bubblewrap
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
bubblewrap is already the newest version (0.9.0-1ubuntu0.1).

I've also did apt-get install --reinstall bubblewrap.

I see no related apparmor profiles:
% rg 'bubblewrap|bwrap|codex' /etc/apparmor*

But I also do not see any evidence that apparmor profiles are supposed to be installed with bubblewrap. There are no dependencies for it:

% apt info bubblewrap | grep -iE "depend|recomm"

Depends: libc6 (>= 2.38), libcap2 (>= 1:2.10), libselinux1 (>= 3.1~)
Recommends: procps

I did apt source bubblewrap to download source, but cannot find the word 'apparmor' anywhere in files or file names:

% cd bubblewrap-0.9.0
% rg -i apparmor
% find -iname "*apparmor*"

Extra data

I'm running this on a regular laptop, not in a container or VM.

% codex --version
codex-cli 0.118.0

% grep PRETTY /etc/os-release
PRETTY_NAME="Ubuntu 24.04.4 LTS"

% codex sandbox linux -- ls
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

% grep bwrap /var/log/kern.log
....
2026-04-08T12:30:45.809942+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.808:3975): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=204598 comm="bwrap" requested="userns_create" target="unprivileged_userns" execpath="/usr/bin/bwrap"
2026-04-08T12:30:45.810879+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.809:3976): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=204600 comm="bwrap" capability=8  capname="setpcap"
2026-04-08T12:30:45.810886+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.809:3977): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=204600 comm="bwrap" capability=12  capname="net_admin"
2026-04-08T12:30:45.812952+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.811:3978): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=204597 comm="bwrap" requested="userns_create" target="unprivileged_userns" execpath="/usr/bin/bwrap"
2026-04-08T12:30:45.813938+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.812:3979): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=204602 comm="bwrap" capability=8  capname="setpcap"
2026-04-08T12:30:45.813944+02:00 nlx000007 kernel: audit: type=1400 audit(1775644245.812:3980): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=204602 comm="bwrap" capability=12  capname="net_admin"

@geomander : have a look at my post a bit ealier in the thread: apt install apparmor-profiles
But also have a look at the other issues you might run into with for example flatpak if you happen to use that.

@cs224 Yes, I did read it all, but I use Flatpak and containers extensively, and apparmor_restrict_unprivileged_userns is a security feature that adds protection in both of those contexts. So globally disabling it does not seem like the right solution to me. --enable use_legacy_landlock, however, does work as a workaround.

But this issue is marked as closed, and the two dev comments:

...apt-get install bubblewrap, which installs the correct AppArmor policy for Codex to work...
and
This should be fixed in 0.117.0.

make it sound like the issue is considered fixed. I cannot confirm that on my end, so either I am missing something, or maybe the issue was considered resolved prematurely.

Reading state information... Done
bubblewrap is already the newest version (0.9.0-1ubuntu0.1).
0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.
root@nyx:/home/john/wardline#

Newest bubblewrap doesn't fix it.

codex-cli 0.118.0

Ok, I did some research and testing. I believe there are 2 solutions that align with the official way Ubuntu does these things in 24.04, neither of which requires globally disabling apparmor_restrict_unprivileged_userns. It should be noted that apparmor_restrict_unprivileged_userns is an Ubuntu-specific thing that denies apps run as regular users from creating namespaces (the thing that makes containers and bwrap-sandoxing work), unless they specifically have been allowed to.

Solution 1: Allow bwrap to create namespaces

Ubuntu 24 already uses this method in over 90 other AppArmor profiles. So we just create what is basically a copy of one of these existing profiles, e.g. /etc/apparmor.d/flatpak, and replace the names inside with bwrap.

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile bwrap_userns /usr/bin/bwrap flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/bwrap>
}

Save it as /etc/apparmor.d/bwrap-userns and load it with sudo apparmor_parser /etc/apparmor.d/bwrap-userns.

This allows bwrap to create namespaces at will. This should "just work(tm)", but the drawback is that this also allows any program inside the sandbox to create namespaces, which is less strict than it could be. And so Ubuntu attempted to implement a stricter version, which is Solution 2 below.

Rolling back

If you want to roll back this change later, do sudo apparmor_parser -R /etc/apparmor.d/bwrap-userns and then sudo rm /etc/apparmor.d/bwrap-userns (in that order).

Solution 2: bwrap-userns-restrict

In Ubuntu 24.04.02 they added the bwrap-userns-restrict AppArmor profile, which allows bwrap to create a namespace, but children of bwrap will _not_ be allowed to do so. Unfortunately, the update broke a lot of Flatpaks and they had to roll the change back.

I still mention it here, because it seems like the slightly better solution if it works. And in fact _none of my Flatpaks exhibit any problems_. If it breaks for you, you can just roll back this solution and use solution 1.

sudo apt install apparmor-profiles
sudo ln -s /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/bwrap-userns-restrict

Then load the profile with sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict and test.

Rolling back

If you want to roll back this change later, do

sudo apparmor_parser -R /etc/apparmor.d/bwrap-userns-restrict
sudo rm /etc/apparmor.d/bwrap-userns-restrict
sudo apt remove apparmor-profiles

in that order.

---

@cs224 you mentioned that some of your Flatpaks broke. Could you name some examples? I'd love to test here. Ubuntu only made minor changes to the bwrap-userns-restrict profile in 25.04, so it would be interesting to see if those minor changes would fix the issues you saw, under 24.04.

I hit this issue on Ubuntu 24.04 with codex 0.120.0. What worked for me was running codex features enable use_legacy_landlock as suggested here by filimonov.

Before, I tried some of the fixes suggested by others. They didn't fix the issue, and surprisingly the agent still could edit files by running commands even if bwrap was failing. See the output from codex exec --json here - one tool call fails, another succeeds.

It's worrying that only some of the tools are sandboxed via bwrap. It's also worrying that gpt-5.2 itself says that Ubuntu intentionally doesn't ship with bwrap-userns-restrict since it circumvents system security restrictions.

It's also worrying that gpt-5.2 itself says that Ubuntu intentionally doesn't ship with bwrap-userns-restrict since it circumvents system security restrictions.

No. The _opposite_ is true.

bwrap-userns-restrict enforces security restrictions that would otherwise be bypassed by running an unconfined profile. It was disabled in 24.04.3 because these added restrictions were breaking certain Flatpaks. It was reintroduced in 25.04 (see release notes https://documentation.ubuntu.com/release-notes/25.04/) and is now part of the default install.

I think either gpt-5.2 is gaslighting you or maybe you misunderstood the reply it gave you. :)

https://github.com/openai/codex/issues/18800

this workaround is being removed soon!

codex --enable use_legacy_landlock

https://github.com/openai/codex/issues/14919#issuecomment-4076504751

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

This works with latest codex after 5.5 update

This is still broken as of build 124, ubuntu 24.04 LTS

I've been running FIO benchmarks using Codex, but they are failing due to permission issues. Could you provide an option to temporarily disable the sandbox when requested by the user?

• I’m retrying the doc updates now.

• I tried, but the same shell-layer failure is still blocking any file write through command execution:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

This is on version 0.124.0

As far as I can tell this issue was closed prematurely, as the problem still persists on Ubuntu 24.04 with bubblewrap installed on latest codex (0.128.0 as of this writing). Basic sandbox edit operations fail, which significantly impedes normal work. Only the use_legacy_landlock setting reliably fixes it for me.

Please don't remove use_legacy_landlock until there is actually a fix or workaround for LTS users that doesn't involve disabling AppArmor security features.

@eloquence did you try an AppArmor profile for bwrap? I mentioned it earlier, but it may have been buried.

I've put together a guide to fixing this so we have something to link to: https://github.com/dfaerch/bubblewrap-on-ubuntu

Thanks @dfaerch - I've not tried this yet, but if this is going to be the final word from OpenAI on this issue, that does seem like the way to go.

However, IMO at a minimum Codex itself should attempt to _detect_ the sandbox issue and offer a path to resolution, before considering this issue resolved. That resolution path, as your approach suggests, should indeed be minimally invasive as fixing the behavior of one application should not require weakening a system-wide security setting that exists for good reasons.

@dfaerch @eloquence does the instructions for Ubuntu 24.04 not work for you? https://developers.openai.com/codex/concepts/sandboxing#prerequisites (if you scroll past a bit)

@dfaerch @eloquence does the instructions for Ubuntu 24.04 not work for you? https://developers.openai.com/codex/concepts/sandboxing#prerequisites (if you scroll past a bit)

Following those do make codex work, but breaks other things using bwrap (ie flatpak), which is why the bwrap-userns-restrict was rolled back and not installed by default in 24.04.

There are more details on this in my repo readme, including how to fix it.

@viyatb-oai I can confirm that the instructions do work. I don't use Flatpak, so I can't speak to the breakage that @dfaerch mentions, but that seems important to at least acknowledge in the docs to avoid users breaking something else by attempting to get Codex to work.

In general, FWIW, this messing around with AppArmor settings feels very brittle and it might be advisable to support a first class fallback option until system configuration changes are no longer necessary on any mainline LTS release. Users could still be given a warning that they are running on a lower security sandbox, and instructions to resolve.

I should also note that contrary to what the docs say, I did _not_ get a startup warning prior to running these instructions. Here's a direct copy/paste of my session.

erik@liminal:~/Code/t2 $ codex


╭──────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.128.0)                   │
│                                              │
│ model:     gpt-5.5 medium   /model to change │
│ directory: ~/Code/t2                         │
╰──────────────────────────────────────────────╯

  Tip: New Use /fast to enable our fastest inference with increased plan usage.


› Create a file with the content @foo to test the sandbox.


• I’ll create a small file in the workspace with exactly @foo as its contents, then verify it.

• The initial sandboxed command failed before reaching the shell because of the filesystem sandbox setup. I’m going to request the same simple workspace write
  outside that wrapper so I can complete the file creation.

■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.
Token usage: total=9,114 input=9,028 (+ 6,528 cached) output=86

As you can see there is no warning message about the sandbox initialization, nor any pointer to a workaround.