Plugin runtime ignores sandbox_mode from config.toml; unusable on kernels with apparmor_restrict_unprivileged_userns=1 (bwrap loopback failure) while direct codex exec works

Environment

• Ubuntu 24.04, kernel 6.8.0-107-generic, default hardening: kernel.apparmor_restrict_unprivileged_userns = 1
• codex-cli 0.144.1 (npm global install)
• Plugin: codex@openai-codex 1.0.6 (marketplace openai/codex-plugin-cc)
• Claude Code CLI, node v22.13.1
• Auth: ChatGPT login, verified working

Symptom

Every Codex invocation that goes through the plugin's managed runtime (scripts/codex-companion.mjs → app-server/broker) fails at turn init, before any command is attempted:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Root cause of the bwrap failure itself is the Ubuntu 24.04 default apparmor_restrict_unprivileged_userns=1, which prevents unprivileged user-namespace creation. That part is an OS policy, not a plugin bug.

The plugin bug: the managed runtime does not honor the user's sandbox_mode setting, so there is no way to make the plugin work on such hosts even though the standalone CLI works fine.

What we verified

1. Added top-level sandbox_mode = "danger-full-access" to ~/.codex/config.toml.
2. Direct CLI in the same environment now works — codex exec --skip-git-repo-check "run: git log --oneline -3" gathers evidence and returns output normally.
3. Killed the plugin's stale broker/app-server (app-server-broker.mjs under /tmp/cxc-*) so the next plugin invocation starts a fresh runtime with the new config → still fails with the identical bwrap error.
4. Started a completely fresh conversation thread (no resume) through the plugin → still fails identically.

So: same host, same config, same CLI binary — direct codex exec respects sandbox_mode and runs; the plugin-managed runtime forces bwrap sandbox setup regardless and dies.

Expected behavior

Either (any of these would resolve it):

• The plugin-managed runtime honors sandbox_mode from ~/.codex/config.toml, or
• The plugin exposes an equivalent option of its own, or
• On bwrap/userns init failure, the runtime degrades gracefully (or at minimum surfaces actionable guidance mentioning apparmor_restrict_unprivileged_userns), instead of failing every turn with a raw bwrap error.

Repro steps

1. Ubuntu 24.04 host with default kernel.apparmor_restrict_unprivileged_userns = 1.
2. Install codex-cli globally + the codex@openai-codex Claude Code plugin; log in.
3. Set sandbox_mode = "danger-full-access" at top level of ~/.codex/config.toml.
4. Invoke any plugin flow (e.g. the codex-rescue agent) → bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted on every turn.
5. Run codex exec from a plain shell in the same directory → works.

Impact

The plugin is entirely unusable on default-hardened Ubuntu 24.04 hosts, while the standalone CLI works after one config line. Users hit a raw bwrap error with no pointer to the actual knob.

Start with scripts/codex-companion.mjs and the app-server/broker path, including the app-server-broker.mjs process under /tmp/cxc-*. Compare how this managed runtime reads sandbox_mode with the standalone codex exec behavior, then reproduce on Ubuntu 24.04 with apparmor_restrict_unprivileged_userns=1. Done means the configured mode is honored or the failure provides actionable guidance instead of the raw bwrap error.