apply_patch and managed sandbox fail with Bubblewrap loopback/userns errors on Ubuntu 24.04

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

• #29052

Powered by Codex Action

Adding severity/context: this is not just extra approval prompts.

When the managed sandbox hits this Bubblewrap/AppArmor failure, the coding workflow is effectively unusable:

• apply_patch, the expected file-edit path, cannot read or update files inside the configured writable workspace.
• Basic local commands can fail before execution.
• The fallback is to approve unsandboxed commands, which removes the intended workspace-write safety model and causes repeated interruptions.
• For coding tasks, this means the main product path (inspect -> patch -> verify) is broken on affected Ubuntu/AppArmor setups.

This is related to #29052 / #29043, but those are framed mostly as approval-prompt regressions. This issue is specifically that the supported sandboxed edit/tool path cannot function at all.

Additional datapoint: launch context appears to matter.

After starting Codex from the VS Code integrated terminal, managed workspace-write is currently working on the same machine/environment class:

• sandboxed id succeeds
• sandboxed git status --short --branch succeeds
• apply_patch can create and delete a scratch file successfully

Earlier failures with the same reported Bubblewrap error occurred under a different launch/session context. This suggests the issue may depend on how the Codex process/tool runner is launched or initialized, not only on the host OS settings.

I can reproduce a closely related bwrap loopback failure on another Ubuntu 24.04-family environment.

Environment

• Codex CLI: 0.142.0
• OS: Ubuntu 24.04 family
• Kernel: Linux 6.17.0-29-generic
• Bubblewrap: bubblewrap 0.9.0
• bwrap path: /usr/bin/bwrap
• kernel.unprivileged_userns_clone = 1
• user.max_user_namespaces = 255645
• kernel.apparmor_restrict_unprivileged_userns = 1

Minimal reproduction

Outside Codex, this fails with the same loopback error:

bwrap --unshare-net --dev-bind / / true

Result:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

A related non-network probe also fails:

bwrap --dev-bind / / true

Result:

bwrap: setting up uid map: Permission denied

Codex behavior

Codex shell commands fail before the requested command body runs. This looks like a Codex CLI sandbox / bubblewrap / Ubuntu AppArmor interaction rather than a repository command failure.

Local workaround

I did not change OS AppArmor/sysctl settings, and I did not use --dangerously-bypass-approvals-and-sandbox as a default.

As a local workaround, I used an explicit opt-in profile:

# ~/.codex/no-bwrap.config.toml
sandbox_mode = "danger-full-access"
approval_policy = "on-request"

Then launched Codex with:

codex -p no-bwrap -C /path/to/repo

With that opt-in profile, a nested codex exec that ran pwd completed successfully.

Suggestion

A codex doctor preflight check or a more actionable error message for this bwrap fingerprint would make this easier to diagnose without changing the default sandbox policy.

I’m happy to look into a small diagnostic-only PR around codex doctor if that direction sounds reasonable to the maintainers.

I can reproduce the same class of issue in a Docker/devcontainer setup, and I think the impact is broader than just the initial bwrap startup failure.

In my case, the core problem is that apply_patch and normal workspace-confined edits are coupled to the Linux bwrap sandbox. When bwrap cannot create namespaces inside the devcontainer, the agent cannot reliably perform normal approved workspace patches.

Environment

• Linux devcontainer / Docker
• Codex sandbox mode: workspace-write
• Approval mode: approval-based / on-request
• Not using danger-full-access
• Desired model: keep approvals, allow normal workspace patches
• kernel.unprivileged_userns_clone = 1

Diagnostics inside the container:

cat /proc/sys/kernel/unprivileged_userns_clone
# 1

unshare -Ur true
# unshare: unshare failed: Operation not permitted

bwrap --version
# bubblewrap 0.11.0

bwrap --ro-bind / / true
# bwrap: No permissions to create new namespace, likely because the kernel does not allow non-privileged user namespaces.

apply_patch behavior

apply_patch is inconsistent:

Creating a new workspace file may succeed:

*** Begin Patch
*** Add File: codex-apply-patch-workspace-test.tmp
+ok
*** End Patch

But deleting or updating an existing workspace file fails because the sandbox helper tries to read the file and hits bwrap:

*** Begin Patch
*** Delete File: codex-apply-patch-workspace-test.tmp
*** End Patch

Observed error:

apply_patch verification failed: Failed to read /workspace/codex-apply-patch-workspace-test.tmp:
fs sandbox helper failed with status exit status: 1:
bwrap: No permissions to create new namespace, likely because the kernel does not allow non-privileged user namespaces.

This makes apply_patch unusable for normal coding work, even though the target file is inside the writable workspace.

Landlock workaround is not sufficient

I also tried:

[features]
use_legacy_landlock = true

This allowed:

codex sandbox -- pwd
# /workspace

But it is not a viable complete workaround. In the same setup, normal tool/shell execution can fail with:

thread 'main' panicked at linux-sandbox/src/linux_run_main.rs:311:9:
permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock

So the available workaround is both deprecated and incompatible with managed permission profiles. It does not provide a reliable replacement for the bwrap path.

Why this matters

The desired security model is:

• keep workspace-write
• keep user approvals
• do not use danger-full-access
• do not loosen the whole devcontainer with seccomp=unconfined / apparmor=unconfined
• do not fall back to shell/perl/python edits for normal code patches
• allow apply_patch to update files inside the workspace

Currently there is no reliable mode that satisfies this.

This is especially problematic because the failure pushes the agent toward less desirable workarounds: asking for broad shell access, editing files through scripts, or requiring users to weaken container security. That is exactly what apply_patch should avoid.

Architectural concern

This looks like an architectural issue, not just a missing package or local Docker misconfiguration.

Ordinary workspace-confined file edits should not depend on a bwrap namespace setup that commonly fails in devcontainers. Other agentic coding tools used in the same development environment do not hit this failure mode, including Claude Code, GitHub Copilot coding agents and Cursor CLI. They still preserve their own approval/permission models, but they do not make normal workspace file edits fail because bwrap cannot create namespaces.

Codex should not require users to choose between:

• loosening the whole container security profile,
• using danger-full-access,
• relying on deprecated Landlock behavior,
• or letting the agent fall back to shell/perl/python edits,

just to perform normal approved workspace patches.

Expected behavior

Codex should provide a safe patch path that does not fail when bwrap cannot create namespaces inside a devcontainer.

Possible acceptable fixes:

1. Decouple apply_patch from the bwrap runtime sandbox and enforce workspace boundaries through the Codex permission model.
2. Automatically detect bwrap namespace failures and use a compatible fallback that still preserves approvals and workspace boundaries.
3. Provide a clear actionable error message when no safe fallback exists.
4. Do not leave deprecated Landlock as the only workaround if it is incompatible with managed permission profiles.

Related issues that seem connected:

• #14919
• #15517
• #15434
• #15496
• #24873

Additional confirmed workaround on Ubuntu 24.04: AppArmor userns profile for Codex itself.

I could reproduce the failure with kernel.apparmor_restrict_unprivileged_userns=1 from an unprofiled terminal:

$ cat /proc/self/attr/current
unconfined

$ bwrap --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true
bwrap: setting up uid map: Permission denied

$ bwrap --unshare-net --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Temporarily disabling the Ubuntu AppArmor userns restriction made both probes pass:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
$ bwrap --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true; echo $?
0
$ bwrap --unshare-net --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true; echo $?
0

I did not want to leave that sysctl disabled globally.

The useful clue was that official VS Code from the .deb package worked because Ubuntu ships an AppArmor profile like this:

profile vscode /usr/share/code{/bin,}/code flags=(unconfined) {
  userns,
}

For Homebrew-installed Codex on an x86_64 host, this AppArmor profile fixed apply_patch add/update/delete without relaxing the whole system:

abi <abi/4.0>,

include <tunables/global>

profile codex /home/linuxbrew/.linuxbrew/Caskroom/codex/*/codex-x86_64-unknown-linux-musl flags=(unconfined) {
  userns,

  include if exists <local/codex>
}

Install/load:

$ sudo install -m 0644 apparmor-codex-profile /etc/apparmor.d/codex
$ sudo apparmor_parser -r /etc/apparmor.d/codex

After restarting Codex:

$ cat /proc/<codex-pid>/attr/current
codex (unconfined)

Then apply_patch could update an existing file again.

One narrower profile attempt did not work:

profile codex ... flags=(unconfined) {
  /usr/bin/bwrap Cx -> codex-bwrap,
}

profile codex-bwrap flags=(unconfined) {
  userns,
}

That attached to the Codex process, but Codex still failed with namespace setup errors, which suggests user namespace creation happens before that transition or through a helper path other than direct /usr/bin/bwrap.

So the practical workaround is: keep kernel.apparmor_restrict_unprivileged_userns=1, but add a Codex-specific AppArmor compatibility profile with userns,.

This is narrower than disabling the sysctl globally or profiling the whole terminal, but broader than granting userns only to bwrap.

hey @dpritchett, does the workaround for Ubuntu 24.04 mention on https://developers.openai.com/codex/concepts/sandboxing#prerequisites work for you?

@viyatb-oai, yep!

I tested the documented Ubuntu 24.04 workaround.

Steps:

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

sudo ln -s /etc/apparmor.d/codex /etc/apparmor.d/disable/codex
sudo apparmor_parser -R /etc/apparmor.d/codex

After fully restarting Codex, the Codex process was no longer under my Codex-specific profile:

$ cat /proc/self/attr/current
unconfined

Both bwrap probes then passed:

$ bwrap --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true; echo $?
0

$ bwrap --unshare-net --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 /bin/true; echo $?
0

I also verified that apply_patch can update an existing workspace file. So yes, the documented bwrap-userns-restrict workaround resolves my local failure too while keeping kernel.apparmor_restrict_unprivileged_userns=1.

Thanks for pointing me at the documented path. For completeness, the Codex-specific profile I posted earlier also works, but the distro-provided bwrap-userns-restrict profile is clearly easier to recommend/support for Ubuntu 24.04 users.

Additional reproduction on Codex CLI 0.144.3.

Environment:

• Linux x86_64, Ubuntu generic kernel 6.8.0-134
• bubblewrap 0.9.0
• filesystem sandbox: workspace-write / restricted
• network sandbox: restricted
• repository files use normal Unix group ownership/ACLs and are writable by group; this does not appear to be a repo file permission failure

Observed during a small LICENSE / pyproject / todo.md edit:

• apply_patch failed before reading/updating an in-workspace file:

~~~text
apply_patch verification failed: Failed to read file to update .../pyproject.toml: fs sandbox helper failed with status exit status: 1: bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
~~~

• Some simple sandboxed shell commands also failed with the same error before the requested command ran.
• Retrying those shell commands with escalation worked, but apply_patch has no equivalent escalation path.
• The failure forced much noisier edit/staging workarounds for basic text changes, which increases latency and token/tool usage.

Expected behavior:

• Codex should distinguish this from repository file permissions.
• If loopback setup is unavailable, the managed sandbox should degrade to a profile that still supports basic workspace reads/writes, or expose a supported apply_patch recovery path similar to shell escalation.

This is not a container-only case from the user perspective; the repo is a normal Linux workspace with group-writable files.

Adding another variant of what looks like the same failure class (bwrap sandbox setup failing in restricted environments before the requested command runs).

Environment

• codex-cli 0.144.0
• Ubuntu 24.04.4 LTS, kernel 6.8.0-134-generic
• Failure occurs for a dedicated low-privilege service user running under a restrictive profile (systemd/AppArmor-hardened); the same codex invocation from a regular unrestricted user on the same host works fine
• kernel.apparmor_restrict_unprivileged_userns = 0 globally, kernel.unprivileged_userns_clone = 1 — i.e. the global sysctls are permissive; the restriction comes from the per-service hardening

Observed
Sandboxed exec fails during bwrap setup with an error referencing /proc/sys/kernel/overflowuid (bwrap cannot read it during uid-map/userns setup), so --sandbox read-only and --sandbox workspace-write are both unusable for that user.

Workaround
--sandbox danger-full-access for review-style (read-only-by-convention) tasks. Works, but it means the sandbox is opt-out exactly in the hardened environments where you'd most want it enforced.

Suggestion
Same as the OP's expected-behavior note: a supported fallback (e.g. landlock/seccomp-only mode, or a preflight that detects userns/bwrap unavailability and degrades with a clear message) would help. Happy to run diagnostics if useful.

Another confirmed reproduction on Codex CLI 0.144.5, with a slightly different initial condition: the distro bubblewrap package was not installed, so Codex used its bundled helper.

Environment

• Ubuntu 24.04
• Kernel 6.17.0-1013-aws
• Codex CLI 0.144.5
• command -v bwrap: no result before the fix
• kernel.unprivileged_userns_clone = 1
• user.max_user_namespaces = 125266
• kernel.apparmor_restrict_unprivileged_userns = 1

Observed behavior

Every sandboxed command, including pwd, failed before execution with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Because shell calls could retry with escalation, even routine read-only commands were routed through Auto-review. Each command then produced the review rationale, approval event, and unsandboxed execution event. This made ordinary coding turns very noisy and shifted routine commands outside the intended sandbox boundary.

I did not see a one-time actionable startup diagnostic identifying the missing distro package/AppArmor profile.

Verified fix

sudo apt-get install -y bubblewrap 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

After loading the profile, the existing Codex session immediately ran pwd and git status --short inside the sandbox without Auto-review escalation. AppArmor remained enabled and kernel.apparmor_restrict_unprivileged_userns remained 1.

Suggested improvement

Please preflight the complete Bubblewrap path, including loopback initialization—not only helper presence or basic user-namespace creation. When this fingerprint is detected, Codex could surface one actionable Ubuntu-specific diagnostic instead of repeatedly escalating each command. A codex doctor check for the distro bwrap package and the loaded bwrap-userns-restrict profile would also make this much easier to diagnose.