Better diagnostic when Linux sandbox fails due to AppArmor unprivileged userns restriction

What version of Codex CLI is running?

0.123.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4-codex

What platform is your computer?

Linux 6.8.0-107-generic x86_64 x86_64

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

N/A

What issue are you seeing?

Codex CLI on Ubuntu failed to run even trivial sandboxed commands because the Linux sandbox backend could not create its namespace setup under AppArmor’s unprivileged user namespace restriction.

The current error surfaced to the user was too low-level to be actionable:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

In practice, this made Codex look broken or misconfigured, when the actual problem was host policy.

Sandboxed commands fail with a low-level error:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

A direct namespace test also failed:

unshare -Ur true
# unshare: write failed /proc/self/uid_map: Operation not permitted

System state:

sysctl kernel.unprivileged_userns_clone
# 1

sysctl user.max_user_namespaces
# high/nonzero

sysctl kernel.apparmor_restrict_unprivileged_userns
# 1

What steps can reproduce the bug?

1. Run Codex CLI on Ubuntu Linux (kernel 6.8.0-107-generic) with AppArmor enabled.
2. Ensure:

``bash
sysctl kernel.apparmor_restrict_unprivileged_userns
# 1
``

1. Start a Codex TUI session.
2. Run a trivial sandboxed command (e.g., pwd).
3. Observe failure before execution.

Additional notes:

• Reproducible in normal sandboxed execution.
• Running outside the sandbox still works.
• Rolling back Codex from 0.124.0 to 0.123.0 does not fix it.

What is the expected behavior?

When the Linux sandbox backend cannot initialize because unprivileged user namespaces are blocked by host policy, Codex should emit a higher-level diagnostic instead of only the low-level sandbox error.

Example guidance:

• Sandbox initialization failed
• Unprivileged user namespaces may be blocked by AppArmor or host policy
• Check kernel.apparmor_restrict_unprivileged_userns
• Try a diagnostic like: unshare -Ur true

Additional information

Environment:

• OS: Ubuntu Linux
• Kernel: 6.8.0-107-generic
• Codex CLI versions tested:
• 0.124.0
• 0.123.0 (rollback did not resolve issue)
• Install method: npm global install
• Shell/session type: terminal TUI session

Why this matters:

This issue is difficult to diagnose from the current error output. It can easily appear as:

• A Codex regression
• A bad update
• A broken sandbox mode
• Incorrect approval behavior

In this case, the issue initially appeared to be caused by an update, but was actually due to an AppArmor restriction on the host system.

Suggested improvement:

On Linux, if sandbox startup fails in this class of failure, Codex could:

1. Detect the userns / uid_map failure path
2. Check whether kernel.apparmor_restrict_unprivileged_userns = 1
3. Surface a targeted explanation
4. Clearly distinguish “sandbox backend unavailable” from ordinary approval escalation

Repro note:

Observed on Ubuntu with AppArmor enabled and:

kernel.apparmor_restrict_unprivileged_userns = 1

After setting:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

and restarting Codex, sandboxed execution worked normally again.