Linux workspace-write sandbox fails under AppArmor unprivileged_userns (EACCES /proc/self/setgroups) since 0.81.0

Summary

On Ubuntu with AppArmor enabled and kernel.apparmor_restrict_unprivileged_userns=1, the Linux workspace-write sandbox fails when run from inside a Git repo. This cascades into the interactive CLI repeatedly requesting approvals (because the sandbox cannot start).

This worked in @openai/codex 0.80.0 and regressed in 0.81.0 (and still fails in 0.84.0).

Environment

• codex-cli 0.84.0
• OS/Kernel/Arch: Linux bofh-spark 6.14.0-1015-nvidia #15-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 25 18:02:16 UTC 2025 aarch64
• LSM: lockdown,capability,landlock,yama,apparmor,ima,evm
• Relevant sysctls:
• kernel.apparmor_restrict_unprivileged_userns = 1
• kernel.unprivileged_userns_clone = 1
• user.max_user_namespaces = 511893

Repro steps

1. In any Git repository directory (i.e., the CWD is under a working tree and contains .git/):

``bash
codex sandbox linux --full-auto true
``

1. Run the same command from a directory without .git (e.g. /tmp):

``bash
cd /tmp
codex sandbox linux --full-auto true
``

Expected

• workspace-write sandbox should work, or
• it should fall back (or show a clear, single actionable error) without degrading into repeated per-command approval prompts in the interactive CLI.

Actual

From a Git repo root:

thread 'main' panicked at linux-sandbox/src/linux_run_main.rs:30:9:
error running landlock: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" })
exit=101

From /tmp:

exit=0

Regression check on the same machine:

• @openai/codex 0.80.0: codex sandbox linux --full-auto true exits 0
• @openai/codex 0.81.0: fails as above (exit 101)
• @openai/codex 0.84.0: fails as above (exit 101)

Diagnostics

strace shows the failure occurs during the userns/mount setup:

unshare(CLONE_NEWNS|CLONE_NEWUSER) = 0
openat(AT_FDCWD, "/proc/self/setgroups", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)

Kernel log shows AppArmor denying CAP_SYS_ADMIN in the unprivileged_userns profile for the process:

apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" comm="codex" capability=21 capname="sys_admin"

Suspected cause

The Linux workspace-write sandbox now performs the “Git safety mounts” path (user namespace + mount namespace to bind-mount .git / .codex read-only). On systems with kernel.apparmor_restrict_unprivileged_userns=1, this path appears to be blocked by AppArmor, so sandbox setup fails.

Possible fixes / ideas

• Detect this failure and fall back to a mode that still keeps .git / .codex immutable without requiring userns/mount namespaces (e.g., a Landlock ruleset that grants RW to enumerated workspace children excluding .git / .codex, or a configurable alternative).
• At minimum, handle this gracefully and avoid turning it into repeated per-command approval prompts in the interactive CLI.

Happy to test patches on this machine.