›_ Codex Issues
Codex Issues / #17337

Linux sandbox failure (bwrap: Failed RTM_NEWADDR) causes all workspace edits to require sandbox bypass

Resolved 💬 6 comments Opened Apr 10, 2026 by cramjaco Closed Apr 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.8.0-100-generic x86_64 x86_64

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

GNOME Terminal 3.52.0

What issue are you seeing?

What issue are you seeing?

Codex cannot perform file edits within the workspace under the default Linux sandbox. Even trivial operations (e.g., creating a new file) fail and trigger:

Reason: command failed; retry without sandbox?

This occurs consistently in normal writable directories.

Direct sandbox commands also fail:

codex sandbox linux -- pwd

with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

As a result, Codex cannot execute any sandboxed commands and requires bypassing the sandbox for all edits.

What steps can reproduce the bug?

  1. Start Codex in a normal writable directory:

mkdir -p ~/Projects/CodexTest
cd ~/Projects/CodexTest
codex

  1. Enter the prompt:

Please create a test file Test.md

  1. Codex proposes the edit, then fails with:

Reason: command failed; retry without sandbox?

What is the expected behavior?

Sandbox should function under workspace-write
Codex should be able to create/edit files in the current workspace without requesting sandbox bypass

Additional information

The following workaround failed.

Configuration

Codex reads configuration from:

~/.codex/config.toml

If this file does not exist, create it:

mkdir -p ~/.codex
nano ~/.codex/config.toml

Add the following:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Save the file and restart Codex.

This does not resolve the issue.

This workaround worked

Workaround

Edit the same config file:

nano ~/.codex/config.toml

Add:

[features]
use_legacy_landlock = true

Full example config:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[features]
use_legacy_landlock = true

Save the file and restart Codex.

After enabling this:

codex sandbox linux -- pwd succeeds
Codex can create/edit files normally within the workspace

Notes
Issue persists across versions (0.117.0 and 0.118.8)
Appears specific to Linux sandbox (bubblewrap) path
Likely interaction with Ubuntu 24.04 / AppArmor user namespace restrictions
Landlock fallback works reliably, suggesting regression or incompatibility in bwrap-based sandbox

Summary

The bwrap-based sandbox fails on Ubuntu 24.04 with:

Failed RTM_NEWADDR: Operation not permitted

This breaks all normal Codex editing workflows unless sandbox bypass is allowed.

The Landlock fallback (use_legacy_landlock = true) fully resolves the issue.

Impact
Prevents basic usage of Codex CLI on affected Linux systems
Forces users to disable sandbox protections or manually approve every edit
Likely affects multiple users on modern Ubuntu systems

Related

This behavior appears similar to other recent reports of sandbox-related failures (e.g., issue #12888).

Thanks for taking a look — happy to provide additional diagnostics if useful.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #16334
  • #15982
  • #16451
  • #16407
  • #16402

Powered by Codex Action

viyatb-oai contributor · 3 months ago

@cramjaco you need to install Bubblewrap for your linux distribution - https://developers.openai.com/codex/concepts/sandboxing#prerequisites

mikkom-aimbition · 3 months ago

Currently your default sandbox configuration FAILS on all vanilla ubuntu based systems - you need to fix it or provide clear instructions on how to get bubblewrap working on defauly Ubuntu installation.

DO NOT REMOVE THE LEGACY CONFIG before you have provided documentation and tested yourself how to get your default sandbox working on default Ubuntu installation.

cramjaco · 2 months ago

Thanks @viyatb-oai . I checked this.

I installed bubblewrap, but the bwrap sandbox path still fails when I disable the Landlock fallback.

Test:

~/.codex/config.toml has use_legacy_landlock commented out
codex sandbox linux -- pwd

Result:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

If I re-enable:

[features]
use_legacy_landlock = true

then codex sandbox linux -- pwd succeeds and normal file edits work again.

So installing bubblewrap by itself does not resolve the issue on my Ubuntu 24.04.4 system. It appears the failure is still specific to the bwrap/AppArmor path.

cramjaco · 2 months ago

Questions about why this is closed. This is indeed duplicate to other issues, but they seem to all be closed as well. Is there an open issue that I should be following/commenting on or is this more of a "wont solve" problem?

viyatb-oai contributor · 2 months ago

@cramjaco @mikkom-aimbition i've added a special section for ubuntu 24.04 in the docs - please let know if the instructions on https://developers.openai.com/codex/concepts/sandboxing#prerequisites don't work you!

------

Ubuntu AppArmor note: On Ubuntu 25.04, installing bubblewrap from Ubuntu’s package repository should work without extra AppArmor setup. The bwrap-userns-restrict profile ships in the apparmor package at /etc/apparmor.d/bwrap-userns-restrict.

On Ubuntu 24.04, Codex may still warn that it can’t create the needed user namespace after bubblewrap is installed. Copy and load the extra profile:

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

apparmor_parser -r loads the profile into the kernel without a reboot. You can also reload all AppArmor profiles:

sudo systemctl reload apparmor.service

If that profile is unavailable or does not resolve the issue, you can disable the AppArmor unprivileged user namespace restriction with:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0