bwrap: Approval prompt shown for almost every command

[nsrisakolkit]

What version of Codex CLI is running?

CLI 0.115.0

What subscription do you have?

GPT Plus

Which model were you using?

gpt-5.3-codex medium

What platform is your computer?

Linux 6.17.0-19-generic x86_64 x86_64

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

No response

What issue are you seeing?

After upgrading to codex-cli 0.115.0, Codex CLI prompts for approval on alomost every command, including safe read-only commands (e.g. find, sed, ls).

Approval decisions such as “don’t ask again” are not persisted, causing repeated prompts and making the CLI difficult to use.

What steps can reproduce the bug?

1. Start Codex CLI:

codex

2. In the prompt, enter:

Analyze the repository structure and summarize the architecture

3. When Codex tries to run a command (for example):

find . -maxdepth 3 -type d | sed 's#^./##' | sort

4. When prompted, select:

Yes, and don't ask again

5. Observe that Codex continues execution and then prompts again for another command

6. Repeat step 4 (approve with “don’t ask again”)

7. Observe that:

• Codex continues to ask for approval on every command
• Even identical or similar commands (find, ls, sed, etc.) trigger prompts again
• Approval choice is not remembered within the same session

What is the expected behavior?

• Safe commands (find, ls, sed, etc.) should not require repeated approval in:
  • /approvals auto
  • -a never
• “Don’t ask again” should persist within the session

Additional information

No response

[github-actions]

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

• Harness Misclassifying Commands? Yolo not yoloing #13663

Powered by Codex Action

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

[ghztomash]

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

[ghztomash]

Downgrading to codex-cli 0.114.0 seems to solve the issue

[sanchopansa]

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

[SRNissen]

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.

[d347h-eth]

[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

[ultmaster]

Same problem here and reverted to 0.114.

[Xynonners]

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.