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.

I wanted to report back after testing the documented Ubuntu 24.04 solution.

I originally reproduced this issue (see #17337). At that time I was only able to get workspace-write working by enabling the legacy Landlock fallback.

I have now tested the documented bwrap-userns-restrict AppArmor profile on Ubuntu 24.04.4 LTS with Codex CLI 0.144.2.

Results:

• kernel.apparmor_restrict_unprivileged_userns = 1 remains enabled.
• unshare -Urn true still fails for an ordinary user, as expected.
• codex exec works normally in workspace-write.
• Sandboxed file reads and writes both succeed.
• The configuration continued working after a reboot.

So, at least on my system, the documented Ubuntu 24.04 procedure resolves the issue without disabling the global AppArmor restriction.

One small suggestion: when Codex encounters

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

it might be helpful if the error message pointed users directly to the Ubuntu 24.04 AppArmor instructions, since that appears to be the supported solution.

I can reproduce the same failure family in a VS Code Dev Container running under Docker on WSL2.

Environment

• Host: Windows 11 with WSL2
• Remote environment: Linux VS Code Dev Container
• Container user: non-root, UID/GID 1000
• VS Code extension: openai.chatgpt@26.727.40816
• Installed Codex CLI versions tested: 0.145.0 and 0.146.0

Inside the Dev Container:

$ unshare --user --map-root-user true
unshare: unshare failed: Operation not permitted

The same user-namespace test succeeds on the WSL2 host, so this appears to be a nested Docker/Dev Container namespace restriction rather than only the Ubuntu 24.04 host AppArmor case described in the documented workaround.

Minimal comparison test

I created the following disposable file in the workspace:

/workspaces/<project>/.codex-sandbox-test.txt

Its initial contents were:

before

I then requested the same operation through both launch paths:

Update .codex-sandbox-test.txt from before to after using apply_patch.

VS Code extension result

The VS Code extension failed before it could read or update the existing file:

apply_patch verification failed: Failed to read file to update /workspaces/<project>/.codex-sandbox-test.txt:
fs sandbox helper failed with status exit status: 1:
bwrap: No permissions to create a new namespace, likely because the kernel does not allow non-privileged user namespaces.

After the failure, the file contents remained:

before

The file was normally readable and writable from the Dev Container terminal.

Codex CLI result

In the same container, with the same user, workspace and test file, I started Codex CLI explicitly with:

codex \
  --sandbox danger-full-access \
  --ask-for-approval on-request

I requested the same apply_patch operation.

This time the operation succeeded, and the file contents changed to:

after

I reproduced this result with Codex CLI 0.145.0 and again after upgrading to 0.146.0.

Configuration observation

A Codex CLI session started without explicit flags also reads the following top-level config.toml settings correctly:

sandbox_mode = "danger-full-access"
approval_policy = "on-request"

Its /status output reports:

Permissions: Custom (danger-full-access, Ask for approval)

However, the VS Code extension’s apply_patch filesystem helper still attempts to use the failing bwrap path.

Comparison

| Launch path | Requested change | Result | Final file contents |
| -------------------------------------------- | -------------------------------------- | ------------------------------------------- | ------------------- |
| VS Code extension | before → after using apply_patch | Fails through the bwrap filesystem helper | before |
| CLI with explicit danger-full-access flags | before → after using apply_patch | Succeeds | after |

Current workaround

For development work, I am using an explicit wrapper around:

codex \
  --sandbox danger-full-access \
  --ask-for-approval on-request

I did not weaken the Dev Container with any of the following:

privileged: true
cap_add:
  - SYS_ADMIN
security_opt:
  - seccomp=unconfined

I also removed the host Docker socket mount before using danger-full-access.

Possible improvement

It would be helpful if Codex could:

1. detect that bwrap cannot create the required namespaces inside a Dev Container;
2. provide a supported fallback for apply_patch that preserves approvals and workspace boundaries;
3. allow the filesystem helper to use the explicitly selected permission mode consistently; or
4. provide a clear diagnostic explaining that the nested container environment does not support the required sandbox backend.

The main additional datapoint is that the same disposable file update fails through the VS Code extension but succeeds through explicitly launched Codex CLI. The extension-side failure remained after the installed Codex CLI was upgraded from 0.145.0 to 0.146.0, while the explicitly launched CLI succeeded with both versions.

Additional workaround for Codex's bundled Bubblewrap

I hit the same bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted failure on Ubuntu 24.04.4, but in my case enabling Ubuntu's standard bwrap-userns-restrict profile alone did not resolve it.

The important difference was that Codex was not using /usr/bin/bwrap. It was using its bundled helper:

/home/<user>/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-resources/bwrap

Because Ubuntu's standard AppArmor profile matches /usr/bin/bwrap, the bundled Codex helper continued to fall through to the generic unprivileged_userns profile and was denied setpcap and net_admin.

I created an AppArmor profile based on Ubuntu's supplied bwrap-userns-restrict profile, but matched it against:

/home/<user>/.codex/packages/standalone/releases/*/codex-resources/bwrap

After loading that profile, the bundled Codex bwrap succeeded.

I then verified apply_patch by:

1. adding a temporary comment to an existing README;
2. removing the same comment again.

Both operations completed using the normal patch helper, with no shell/perl/python fallback and no namespace error.

So for installations where Codex continues to use its bundled bwrap, extending the distro AppArmor approach to the bundled helper path appears to be another working option while keeping:

kernel.apparmor_restrict_unprivileged_userns = 1

Environment:

• Ubuntu 24.04.4 LTS
• Kernel 6.8.0-137-generic
• AppArmor 4.0.1
• Bubblewrap 0.9.0
• Codex standalone 0.145.0

Happy to post the exact AppArmor profile if useful.

Update: I upgraded the standalone Codex install to 0.147.0, fully restarted the remote Codex processes, and re-tested apply_patch.

Result:

• Patch helper used successfully: Yes
• Fallback editing method required: No
• Bubblewrap/AppArmor/namespace/sandbox error: None

The targeted AppArmor workaround for Codex's bundled bwrap therefore still works on 0.147.0 in this environment, while keeping:

kernel.apparmor_restrict_unprivileged_userns = 1

enabled globally.

Confirmed recurrence on the current standalone release with a more specific AppArmor diagnosis.

Environment

• Ubuntu 24.04.4 LTS
• Kernel 6.17.0-1022-gcp
• Google Cloud VM
• Codex standalone codex-cli 0.147.0
• Codex-managed standalone install (not npm/bun)
• No Ubuntu bubblewrap package installed; Codex uses its own bundled codex-resources/bwrap
• kernel.unprivileged_userns_clone = 1
• kernel.apparmor_restrict_unprivileged_userns = 1
• AppArmor unprivileged_userns profile enforcing

Reproduction

A read-only command such as pwd can succeed, but a command requiring the normal workspace-write sandbox fails before the requested command executes:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

apply_patch fails at sandbox initialization as well:

apply_patch verification failed:
fs sandbox helper failed:
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

A controlled test confirmed the target file was never read or modified. A normal shell write outside the failing managed sandbox succeeds, so this is not a repository/filesystem permission problem.

AppArmor evidence

Kernel audit entries emitted at the exact reproduction times show the bundled Codex bwrap transitioning from unconfined to the unprivileged_userns profile and then receiving capability denials including:

apparmor="DENIED" capname="setpcap"
apparmor="DENIED" capname="net_admin"

The execpath in the audit log points to the Codex-bundled codex-resources/bwrap.

This matches the failure point: bwrap creates the sandbox namespace and then cannot configure the loopback address because CAP_NET_ADMIN is denied, producing the RTM_NEWADDR error.

Namespace checks

• unshare -U true succeeds
• root mapping / network namespace variants are denied under the Ubuntu AppArmor userns policy
• no evidence of seccomp being the cause (Seccomp: 0 in the relevant Codex process context)

Update status

The standalone CLI's supported updater is codex update (not codex --upgrade in this build). Running the official updater on 2026-08-11 resolved the latest available version as 0.147.0; the issue remains reproducible afterward.

Security consideration

I have intentionally not disabled AppArmor, set kernel.apparmor_restrict_unprivileged_userns=0, granted capabilities to the bundled bwrap, made it setuid, or run Codex as root. A fix/fallback in Codex would be preferable to requiring a host-wide weakening of Ubuntu's security policy.

This appears to be the same root issue reported here, still present in standalone 0.147.0.

Confirmed on the current standalone release (codex-cli 0.149.1).

Environment:

• Ubuntu 24.04.4 LTS
• Kernel 6.8.0-138-generic
• Codex standalone 0.149.1 (x86_64-unknown-linux-musl)
• System Bubblewrap 0.9.0
• Codex also ships a bundled codex-resources/bwrap
• kernel.unprivileged_userns_clone = 1
• kernel.apparmor_restrict_unprivileged_userns = 1
• user.max_user_namespaces = 62106
• apparmor-profiles and apparmor-utils are not installed, so /usr/share/apparmor/extra-profiles/bwrap-userns-restrict and /etc/apparmor.d/bwrap-userns-restrict are absent

Observed behavior:

• ordinary managed commands fail before execution with bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted, then require an escalated retry;
• apply_patch cannot read an existing target file through the filesystem sandbox and falls back to a nonstandard edit path;
• this happens even for read-only commands and is unrelated to repository file permissions or API/provider connectivity.

Minimal host probes:

$ bwrap --ro-bind / / --proc /proc --dev /dev /bin/true
bwrap: setting up uid map: Permission denied

$ bwrap --unshare-net --ro-bind / / --proc /proc --dev /dev /bin/true
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

This also causes the excessive per-command approval behavior described in #34207.

I have not disabled AppArmor or changed the global sysctl. Next I plan to test the documented Ubuntu 24.04 bwrap-userns-restrict workaround. Since this is a standalone Codex install with a bundled helper, it would still be useful for Codex to detect this fingerprint at startup and point directly to the supported remediation (and account for the bundled codex-resources/bwrap path), instead of repeatedly escalating each command.

Follow-up: the Ubuntu AppArmor remediation resolved the failure on my machine without disabling the global restriction.

What I did:

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

Post-fix validation:

$ /usr/bin/bwrap --ro-bind / / --proc /proc --dev /dev /bin/true
echo $?
0

$ codex sandbox --permission-profile ' :workspace ' --cd "$PWD" /bin/true
# (actual command used `--permission-profile ' :workspace '` without spaces)
echo $?
0

The Codex CLI sandbox test now passes, and codex doctor --summary reports:

✓ sandbox restricted fs + restricted network · approval OnRequest
17 ok · 0 fail degraded

A minimal workspace read through the Codex sandbox also exits successfully. I did not change kernel.apparmor_restrict_unprivileged_userns (it remains 1).

Important implementation detail: an execve trace shows Codex CLI 0.149.1 uses /usr/bin/bwrap for the active sandbox path. The Codex-bundled codex-resources/bwrap still fails when invoked directly because the Ubuntu profile matches /usr/bin/bwrap; however, this does not affect the current CLI path.

Persistence: the profile is installed under /etc/apparmor.d/ and the AppArmor service is enabled, so this should survive reboot. It may need reloading after profile/package changes. A startup preflight could detect the known RTM_NEWADDR fingerprint and point users to this supported Ubuntu remediation instead of repeatedly escalating commands.

Additional reproduction: apply_patch blocked at user-namespace initialization

I’m seeing the same apply_patch sandbox failure family in a Codex execution environment.

Observed error

apply_patch verification failed: 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.

The failure occurs before target-file access.

Independent control

unshare --user --map-root-user true

fails with:

Operation not permitted / exit 1.

Relevant diagnostics

/proc/sys/user/max_user_namespaces = 31103
UID/GID maps cover the full 32-bit range
NoNewPrivs=0
Seccomp=2 with two filters
no effective/permitted capabilities
workspace filesystem is writable
ordinary shell write/read/remove succeeds
no target-path permission error
a fresh Codex execution reproduced the same failure

Conclusion supported by the observations

The current Codex execution boundary denies creation of the unprivileged user namespace required by the bwrap-backed patch sandbox. The exact seccomp/LSM/container-runtime rule causing the denial is not observable from inside the current runtime.

This makes apply_patch unusable even though the workspace itself is writable.

I recently moved the workflow to a ChatGPT Business workspace, but I do not have evidence that the account change is causal.

A supported patch path that works when nested/unprivileged user namespaces are unavailable would avoid requiring host-wide security changes.