`apply_patch` fails inside sandbox on Ubuntu 25.10 due to nested `bwrap` namespace error

What version of the Codex App are you using (From “About Codex” dialog)?

0.120.0

What subscription do you have?

Plus

What platform is your computer?

Ubuntu 25.10 / Linux 6.17.0-22-generic

What issue are you seeing?

On Ubuntu 25.10, apply_patch fails at the sandbox layer in Codex CLI, while direct file writes still work.

The failure appears to happen because Codex is already running inside a bwrap sandbox, and the patch path triggers another sandboxed execution that cannot create the required namespaces or network setup.

As a result, I get messages like:

• Failed to apply patch
• The patch tool failed at the sandbox layer
• bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Direct shell writes in the same repo still succeed, so this looks specific to the patch or sandbox path rather than general filesystem permissions.

What steps can reproduce the bug?

1. Start Codex CLI in a trusted repo on Ubuntu 25.10.
2. Use a repo that does not have sandbox_mode = "none" set in ~/.codex/config.toml.
3. Ask Codex to edit files using apply_patch.
4. Observe that the patch operation fails at the sandbox layer.
5. Observe that direct file writes in the same repo can still succeed.

Minimal repros from the same environment also fail:

bwrap --ro-bind / / --proc /proc --dev /dev --unshare-all --die-with-parent /bin/true

bwrap --unshare-net --ro-bind / / --proc /proc --dev /dev /bin/true

Both report namespace or permission failures.

These also fail:

unshare -Ur true

with:

unshare: write failed /proc/self/uid_map: Operation not permitted

and:

unshare -n true

with:

unshare: unshare failed: Operation not permitted

What is the expected behavior?

apply_patch should succeed in a normal trusted local repo, or at minimum fail with a clear explanation and a consistent fallback strategy.

Additional information

Environment

• Codex CLI version: 0.120.0
• OS: Ubuntu 25.10
• Kernel: Linux 6.17.0-22-generic
• Shell: bash

Local checks:

• bwrap --version => bubblewrap 0.11.0
• /proc/sys/kernel/unprivileged_userns_clone => 1
• /proc/sys/user/max_user_namespaces => 2147483647
• kernel.apparmor_restrict_unprivileged_userns => 1

Inside the running Codex tool process:

• Seccomp=2
• NoNewPrivs=1

Repo / config context

Project is marked trusted in ~/.codex/config.toml:

[projects."/home/user/src/projects/ProjectOne"]
trust_level = "trusted"

Global config includes:

approval_policy = "never"

I do not have sandbox_mode = "none" set for this repo.

Actual behavior

apply_patch fails at the sandbox layer with bwrap errors, including:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Relevant log output

From ~/.codex/log/codex-tui.log:

ERROR codex_core::tools::router: error={"output":"bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted\n","metadata":{"exit_code":1,"duration_seconds":0.0}}

I can also see from the live process list that Codex is already running inside bwrap, with arguments including:

--unshare-user --unshare-pid --unshare-net --apply-seccomp-then-exec

So this looks like a nested sandbox or namespace issue.

Why this looks like a Codex sandbox bug

• bwrap is installed and runnable
• kernel user namespace settings appear enabled
• direct file writes still work
• only the patch path fails
• Codex is already inside a bwrap sandbox when the failure occurs

This suggests the patch tool is hitting a nested sandbox path that is not compatible with this environment.

Workaround

Setting this for the repo avoids the issue:

[projects."/home/user/src/projects/ProjectOne"]
trust_level = "trusted"
sandbox_mode = "none"

After that, editing works without hitting the failing sandbox path.

Request

Please investigate whether apply_patch is attempting to enter an additional bwrap sandbox when Codex is already sandboxed, and whether that path is currently broken on Ubuntu 25.10 or AppArmor-restricted environments.

If useful, I can provide more logs or test a debug build.