bwrap: Approval prompt shown for almost every command

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

• #13663

Powered by Codex Action

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. Your codex installation is falling back to read-only instead of workspace-write sandbox mode.

I have the same issue after updating to codex-cli 0.115.0 on Ubuntu noble 24.04

sandbox is failing with exec_command failed ... stderr: "bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Downgrading to codex-cli 0.114.0 seems to solve the issue

I also have the same issue with codex-cli 0.115.0 on Ubuntu 24.04.

This is a workaround that fixes it: sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0, or alternatively you can use the legacy landlock (use_legacy_landlock). I'm wondering what are the security implications of using sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

I am on a pretty updated Ubuntu 24.04 (updated this week), with a fully updated codex cli. Before dinner, it had write access. After dinner, on starting the agent, it prompted for an update, which I applied, and now it prompts for escalation for everything.

I provided feedback within-agent, and it gave me:

Or mention your thread ID 019cfcff-3b4e-7dd2-af11-a1c18596cf85 in an existing issue.

So now I am - this looks like the same issue.

[for Ubuntu 24]
doing blunt system-wide kernel.apparmor_restrict_unprivileged_userns=0 exposes your kernel to exploits, it's an important safeguard that's better left in place.
you can surgically allow only the codex executable to create unprivileged user namespaces though.

1. get the exact full path to the executable behind codex (no symlinks! otherwise it won't work):

readlink -f "$(command -v codex)"

1. create explicit AppArmor configuration for codex:

sudo vim /etc/apparmor.d/codex-userns

content:

# /etc/apparmor.d/codex-userns
abi <abi/4.0>,

include <tunables/global>

# replace this with the real resolved path on your machine from #1
/home/milady/.nvm/versions/node/v24.3.0/lib/node_modules/@openai/codex/bin/codex.js flags=(default_allow) {
  userns,

  include if exists <local/codex-userns>
}

1. load the new config into AppArmor:

sudo apparmor_parser -r /etc/apparmor.d/codex-userns

Same problem here and reverted to 0.114.

Same problem here, however it only seems to happen for certain types of file editing tasks for some reason (inconsistent).

Switching to legacy landlock for now.

For anyone frustrated by the repeated approval prompts — while this gets fixed upstream, I built Antigravity Autopilot which auto-clicks Accept/Run/Continue/Allow/Retry at the OS level using Windows UI Automation (no CDP required).

It works across VS Code, Cursor, Windsurf, and Antigravity IDE — since it operates via the accessibility tree, it can't be broken by IDE updates or sandbox changes like the bubblewrap issue here.

Marketplace: https://marketplace.visualstudio.com/items?itemName=timteh.antigravity-autopilot-os

For anyone frustrated by the repeated approval prompts — while this gets fixed upstream, I built Antigravity Autopilot which auto-clicks Accept/Run/Continue/Allow/Retry at the OS level using Windows UI Automation (no CDP required).

It works across VS Code, Cursor, Windsurf, and Antigravity IDE — since it operates via the accessibility tree, it can't be broken by IDE updates or sandbox changes like the bubblewrap issue here.

Marketplace: https://marketplace.visualstudio.com/items?itemName=timteh.antigravity-autopilot-os

For anyone frustrated by the repeated approval prompts — while this gets fixed upstream, I built Antigravity Autopilot which auto-clicks Accept/Run/Continue/Allow/Retry at the OS level using Windows UI Automation (no CDP required). It works across VS Code, Cursor, Windsurf, and Antigravity IDE — since it operates via the accessibility tree, it can't be broken by IDE updates or sandbox changes like the bubblewrap issue here. Marketplace: https://marketplace.visualstudio.com/items?itemName=timteh.antigravity-autopilot-os

This issue might be fixed as of v0.116-0-alpha.3 (at least, it fixed #14694 )

[for Ubuntu 24] doing blunt system-wide kernel.apparmor_restrict_unprivileged_userns=0 exposes your kernel to exploits, it's an important safeguard that's better left in place. you can surgically allow only the codex executable to create unprivileged user namespaces though. 1. get the exact full path to the executable behind codex (no symlinks! otherwise it won't work): readlink -f "$(command -v codex)" 2. create explicit AppArmor configuration for codex: sudo vim /etc/apparmor.d/codex-userns content: `` # /etc/apparmor.d/codex-userns abi <abi/4.0>, include <tunables/global> # replace this with the real resolved path on your machine from #1 /home/milady/.nvm/versions/node/v24.3.0/lib/node_modules/@openai/codex/bin/codex.js flags=(default_allow) { userns, include if exists <local/codex-userns> } `` 3. load the new config into AppArmor: sudo apparmor_parser -r /etc/apparmor.d/codex-userns

Thanks @d347h-eth — your solution works in my case.

I was able to fix the issue by following the AppArmor approach you suggested.
In my setup, using:

readlink -f "$(command -v codex)"

For anyone else facing this on Ubuntu 24:

• follow the steps above
• if it doesn’t work, you can also check kernel logs:

sudo journalctl -k | grep -Ei 'userns|bwrap|codex'

and use the execpath= value instead

Closing this as resolved ✅

Closing this as fixed is perhaps a bit premature. It's fine to provide a workaround but there is no mention of any of this in the Codex documentation. Anyone who installs and uses Codex with the current 0-115-0 release will encounter the same issues and probably create yet another clone of this issue (it's already happening - see https://github.com/openai/codex/issues/15074).

I'm honestly having a hard time understanding why this issue wasn't a problem in 0-114-0, if the root cause is attributed to general AppArmor behavior in Ubuntu 24+.

Evidently someone committed a change in 0-115-0 that introduced this behavior, it wasn't caught (which by itself is concerning) and now the issue is being closed simply because a workaround has been identified. What about fixing the actual problem in Codex? Who does that? Will 0-116-0 include a fix for this issue? If not who updates the documentation? Who updates the installation guide? Or are users simply expected to use stubborn determination to scour through closed github issues looking for this workaround?

Many loose ends here.

Closing this as fixed is perhaps a bit premature. It's fine to provide a workaround but there is no mention of any of this in the Codex documentation. Anyone who installs and uses Codex with the current 0-115-0 release will encounter the same issues and probably create yet another clone of this issue (it's already happening - see #15074). I'm honestly having a hard time understanding why this issue wasn't a problem in 0-114-0, if the root cause is attributed to general AppArmor behavior in Ubuntu 24+. Evidently someone committed a change in 0-115-0 that introduced this behavior, it wasn't caught (which by itself is concerning) and now the issue is being closed simply because a workaround has been identified. What about fixing the actual problem in Codex? Who does that? Will 0-116-0 include a fix for this issue? If not who updates the documentation? Who updates the installation guide? Or are users simply expected to use stubborn determination to scour through closed github issues looking for this workaround? Many loose ends here.

Good point, thanks. Reopening the issue as suggested.

0.116 came out, but I still have codex nagging for permission on Ubuntu 24.04. Codex 0.114 works perfectly.

Same as @aukehuizinga - on a fresh new session first grep command is blocked and requires approval.

i still have the same issue when i run codex cli in debian dev container

i still have the same issue when i run codex cli in debian dev container

do you have AppArmor installed? Have you checked its logs for DENIED messages? If so (and there are codex related messages), paste them here.

> i still have the same issue when i run codex cli in debian dev container do you have AppArmor installed? Have you checked its logs for DENIED messages? If so (and there are codex related messages), paste them here.

i didn't install AppArmor - Following are the error messages

✘ Failed to apply patch
└ bwrap: No permissions to create a new namespace, likely because the kernel does not
allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl
kernel.unprivileged_userns_clone=1'.

─────────────────────────────────────

are there any updates on this issue? The IDE extension has the same problem, I tried to open #15322 and raise some attention, but it was marked duplicate as this one.

Apparently, the issue is caused by migration to bwrap, which is currently very flaky. Run this once and enjoy good old behavior, when you approve once and it keeps working on its own:

codex features enable use_legacy_landlock

codex features enable use_legacy_landlock

Finally the right simple answer - thanks @vitaly-castLabs

I’m still seeing this on Linux with:

• approval_policy = "on-request"
• sandbox_mode = "workspace-write"
• features.use_legacy_landlock = true

Enabling legacy Landlock reduces the number of sandbox-related approval requests, but it does not eliminate them. I still get approval prompts for ordinary file reads, and overall behavior is still much noisier than 0.115 with bwrap in the same environment.

So this looks like the workaround only partially mitigates the regression rather than fixing it completely. It may be related to the same sandbox startup / approval-noise family as #15434, but in my case the legacy Landlock path is not a full fix.

This should be fixed in 0.117.0.

This should be fixed in 0.117.0.

It's not, at least not without use_legacy_landlock = true I keep seeing prompts for tool calls and even for simple file edits - a definite regression since 0.114.0.
Using XUbuntu.
This makes it unusable for me so I'm sticking with 0.114.0. If I do use_legacy_landlock = true I guess it may work but I don't want to stick with the legacy sandbox approach forever.

Just pulled 0-118-0 and the issue is not fixed there either. Excessive permission prompts for editing files inside the repo and simple tool calls.

Sorry for the emotional rant but this is depressing. Having to babysit the agent kind of defeats the entire purpose of giving your agent a long running task. It's not long running if it stops every minute asking for permission to proceed.

Right now 0-114-0 is frankly the only usable version of Codex CLI for me.

I can confirm this on Linux too.

I spent some time narrowing it down, and for me the last working version was 0.115.0-alpha.9. Starting with 0.115.0-alpha.11 the problem appears, and 0.115.0 is also broken. Version 0.114.0 still works normally.

The main thing I see is that edits which used to work in workspace-write suddenly start asking for approval, and patch-based edits end up in the same retry without sandbox flow people describe here.

@mamonv @mbetrifork sorry for the frustrating experience! to help debug, can you share the output of these commands? (redact anything sensitive information in the output)

1. what linux distribution are you running on?

cat /etc/os-release
uname -a
lsb_release -a

1. How are you running codex? Is it in a container? (command and relevant configs are helpful)
2. bwrap

which bwrap
bwrap --version
sysctl kernel.unprivileged_userns_clone
bwrap --unshare-user --unshare-net --proc /proc --dev /dev true

@viyatb-oai

1. I'm currently using Ubuntu 26.04, but I have the same problem on 24.04.

cat /etc/os-release
uname -a
lsb_release -a
PRETTY_NAME="Ubuntu Resolute Raccoon (development branch)"
NAME="Ubuntu"
VERSION_ID="26.04"
VERSION="26.04 (Resolute Raccoon)"
VERSION_CODENAME=resolute
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=resolute
LOGO=ubuntu-logo
Linux  7.0.0-10-generic #10-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 19 10:24:42 UTC 2026 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu Resolute Raccoon (development branch)
Release:	26.04
Codename:	resolute

1. I use codex cli and vscode plugin without using containers

3.

which bwrap
bwrap --version
sysctl kernel.unprivileged_userns_clone
bwrap --unshare-user --unshare-net --proc /proc --dev /dev true
/usr/bin/bwrap
bubblewrap 0.11.1
kernel.unprivileged_userns_clone = 1
bwrap: execvp true: No such file or directory

@viyatb-oai

1. Ubuntu 24.04.4 LTS

 ~ 🠞 cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

 ~ 🠞 uname -a
Linux chavao-a72-ion 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 07:58:08 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

 ~ 🠞 lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.4 LTS
Release:	24.04
Codename:	noble

1. I run exclusively using the CLI using zsh on Tilix, the version installed via npm

3.

 ~ 🠞 which bwrap
/usr/bin/bwrap

 ~ 🠞 bwrap --version
bubblewrap 0.9.0

 ~ 🠞 sysctl kernel.unprivileged_userns_clone
kernel.unprivileged_userns_clone = 1

 ~ 🠞 bwrap --unshare-user --unshare-net --proc /proc --dev /dev true
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

I installed the latest alpha version 0.119.0-alpha.27 and the problem was solved. I need to wait for the stable release to check if everything is ok.

Sorry for the slightly off-topic comment but how do I download the 119-alpha version? I have this exact problem as well and I'm thinking the maintainers would want a second confirmation too.

@mberg2007 npm install -g @openai/codex@0.119.0-alpha.27

Sorry to say but 0.119.0-alpha.27 still does not resolve the issue for me:

Edited vitest.config.ts (+1 -0)
     8      setupFiles: ["./vitest.setup.ts"],
     9 +    include: ["src/**/*.test.{ts,tsx}"],
    10      exclude: ["repositories/**", ".ghfixer-runtime/**", "coverage/**"],

• Ran npm run build
  └    ▲ Next.js 15.5.14

    … +30 lines
    ƒ  (Dynamic)  server-rendered on demand

  Would you like to make the following edits?

  Reason: command failed; retry without sandbox?

› 1. Yes, proceed (y)
  2. Yes, and don't ask again for these files (a)
  3. No, and tell Codex what to do differently (esc)

@mberg2007 can you post your relevant configs so I can debug - see https://github.com/openai/codex/issues/14936#issuecomment-4193663633

@mberg2007 can you post your relevant configs so I can debug - see #14936 (comment)

viyatb-oai Sure:

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

$ uname -a
Linux michael-Precision-5690 6.17.0-20-generic #20~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 19 01:28:37 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.4 LTS
Release:        24.04
Codename:       noble

And the bwrap stuff:

/usr/bin/bwrap
bubblewrap 0.9.0
kernel.unprivileged_userns_clone = 1
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

I just launch Codex in bash like this:

$ cd repo-name
repo-name$ codex resume --last

I'm not sure if its relevant but I don't use the npm version, I prefer the standalone binary (unknown-linux.tar.gz)

@mberg2007 - did you install bubblewrap through apt?

@viyatb-oai The package was installed with apt yes. I don't recall doing this manually but I might have - I can be forgetful like that, sorry :-)

But yes:

$ dpkg -S /usr/bin/bwrap
bubblewrap: /usr/bin/bwrap
$ grep "bubblewrap" /var/log/apt/history.log
(no output)
$ dpkg -l | grep bubblewrap
ii  bubblewrap                                    0.9.0-1ubuntu0.1                                 amd64        utility for unprivileged chroot and namespace manipulation

@mberg2007 @viyatb-oai I apologize for the misinformation, but the codex misled me.
It started writing information to files using printf instead of the built-in apply_patch tool. I asked it to test all the tools available to it, and here's the result.
[method: echo >>] - works without confirmation
[method: printf >>] - works without confirmation
[method: tee -a] - works without confirmation
[method: heredoc >>] - works without confirmation
[method: apply_patch] - needs confirmation

tested on stable version 0.120.0

I can add that when I start Codex, I get this yellow warning label emitted by codex as part of its startup:

Codex's Linux sandbox uses bubblewrap and needs access to create user namespaces

Edit:
So I made this change:

Create /etc/apparmor.d/bwrap with this content:

abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
}

Then restarted AppArmor:

$ sudo systemctl reload apparmor

The warning label is now gone when I launch Codex, but I am still prompted repeatedly for approvals for changes inside the repo.

Edit 2:
Switching back to the legacy landlock thing finally solved the issue for me:

$ nano ~/.codex/config.toml
[features]
use_legacy_landlock = true

I can work with this but it doesn't feel like a solution, it feels like a temporary workaround. I hope the actual issue is resolved soon.

FWIW I had these issues up until 118 or something like that. Now I do not have them, despite codex complaining that it uses bundled bwrap. I am actually hesitant to install bwrap as the bundled one seems to work alright ;-)

❮ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian

great, glad that it is working!

@mberg2007 can you install bubblewrap with apt? if you do that, you don't have to change/add AppArmor policies.

@viyatb-oai I tried 0.121 today, Ubuntu 24.04, bubblewrap installed with apt. After a very brief experiment it's somewhat better - managed to run tests and edit files without requiring approval but when Codex wanted to create a new file it still asked for permission which with 0.114 doesn't happen.

great, glad that it is working! @mberg2007 can you install bubblewrap with apt? if you do that, you don't have to change/add AppArmor policies.

As previously stated the bwrap I have was apt-installed. And yes I did need the AppArmor policy adjustment anyway. At least when I added that, the warnings in Codex disappeared.

@viyatb-oai also an update from me. I suddenly started getting issue on some long running codex sessions (using 0.120, seemed to work fine yesterday). I've upgraded to 0.121 - didn't help. Installed bwrap from apt (0.9.0-1ubuntu0.1) - no dice.

I imagine somebody else did something on that linux server, but I am not sure why. Happy to share more system info to help you troubleshoot

can you try reproducing this in 0.122.0-alpha.9? We have a complex migration underway and it seems like it introduced regressions. We fixed this in https://github.com/openai/codex/commit/f705f42ba8e87c455b028623c27d7f0b173b2f10 and https://github.com/openai/codex/commit/63e4a900c95eb4610ce089d57396f19df854b4f1. sorry for the thrash!

I had the same issue, 0.122.0-alpha.9 fixes it for me 👍

On 0.121 the issue is still present.

I realized that the only reason everything worked for me is due to use_legacy_landlock in my settings. It mostly works on 0.122.0-alpha.9 with that option again.

However, without the legacy landlocked mode, which is now warns about deprecations one I have the same AppArmor problem as many others on Ubuntu. The official doc recommendation to use sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 seems a bit too harsh.

I saw 2 suggestions in this thread, one to give codex binary special AppArmor permissions and the other for bwrap. Would be great if codex team will research both and provide the best practice and documentation, rather than relying on blanket config.

@mishamsk if you install bubblewrap using Ubuntu's apt, it should automatically install the relevant AppArmor configs for you. Does that path work for you?

@viyatb-oai i installed via apt but it doesn't seem to have applied any apparmor configuration

I observe the same behavior as mishamsk and mberg2007 with my Ubuntu 24.04 / apt-installed bubblewrap. Please do not remove (or threaten to remove) use_legacy_landlock just yet - bubblewrap is not there yet. Not even close.

@vitaly-castLabs reason behind moving to bubblewrap is that the landlock based sandbox does not allow us to provide options for users to disallow reads or writes from within a writable root. It also does not allow us to provide fine grained network controls like ability to allow/deny domains!

can you please try this? ubuntu also ships with a profile bwrap-userns-restrict with apparmor-profiles that is somehow not on your system.

sudo apt update
sudo apt install apparmor-profiles apparmor-utils

dpkg -L apparmor-profiles | grep bwrap-userns-restrict

sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict

@viyatb-oai thanks, that seems to work on 0.122 (at least a quick test confirmed apply_patch works without landlock and the warning about bwrap not being able to create namespaces is gone). For others I'd modify two things in the recommendation:

sudo apt update
# sudo apt install apparmor-profiles apparmor-utils
# apparmor-utils are not necessary
sudo apt install apparmor-profiles

# Only necessary if extra-profile got installed to a custom path
# dpkg -L apparmor-profiles | grep bwrap-userns-restrict

sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict

# app armor requires restart to pick up the new profile
sudo systemctl reload apparmor

I am not an expert on ubuntu distro's - but probably worth including in docs. Looks like some distro's lack extra profiles

I've updated the docs to reflect this https://developers.openai.com/codex/concepts/sandboxing#prerequisites - please let me know if its missing anything. I'll close this issue!