Codex execution environment cannot use sudo wrapper to reload Caddy

[defangdevs]

Reproduction

On an agent-box Codex session, follow the documented self-serve vhost flow:

1. Write a valid ~/sites/*.caddy snippet.
2. Run sudo /run/current-system/sw/bin/systemctl reload caddy.service.

Both sudo and /run/wrappers/bin/sudo fail before policy evaluation with:

sudo: /nix/store/...-sudo-.../bin/sudo must be owned by uid 0 and have the setuid bit set

/run/wrappers/bin/sudo is present and mode -r-s--x--x, but appears as
nobody:nogroup within the Codex execution environment. This prevents the
documented Caddy reload, even after the vhost snippet was successfully written.

Expected

Codex should be able to use the existing narrowly scoped sudo rule to reload
Caddy, or agent-box should provide an equivalent safe reload path that works in
Codex's execution sandbox.

Environment

• agent-box revision: edb9d9bc7e7033a6be7abd481a82b32a700ea977
• Caddy snippet validation succeeded before reload.
• Existing issue Codex sessions cannot write documented ~/sites Caddy snippets #195 addresses the resolved ~/sites write-path problem, not
  this sudo-wrapper failure.

[defangdevs]

Root cause (reproduced live on an agent-box)

sudo's "must be owned by uid 0 and have the setuid bit set" is codex's own doing, not a sudoers problem. A codex TUI session opted out of codexFullAccess (skipPermissions = false) runs codex's own Linux sandbox (sandbox_mode=workspace-write), which execs commands through an unprivileged bubblewrap user namespace. Root is never mapped inside that namespace, so any setuid-root binary - sudo, whichever wrapper flavor - shows up owned by nobody:nogroup from inside it and refuses outright. That's true of every sudoAllowlist entry, not just the caddy reload; there's no per-command fix on the sudoers side, because this is how unprivileged user namespaces and setuid execution interact by kernel design, not a policy gap.

Reproduced directly:

$ codex exec -c sandbox_mode=workspace-write -c approval_policy=never --skip-git-repo-check --cd /tmp "..."
warning: Codex's Linux sandbox uses bubblewrap and needs access to create user namespaces.
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

That's codex's sandbox failing to even finish setting itself up inside this platform's own hardened session unit - same class of nested-sandbox conflict as agent-box#237's dev-container triage (systemd's ProtectKernelTunables/namespace restrictions on the agent unit don't compose cleanly with a second sandbox layered inside it).

Why codexFullAccess is the intended answer

Issue #234 already made codexFullAccess = true (skip codex's own sandbox entirely) the box-wide default, explicitly because "the box IS the sandbox." A session only hits this bug by opting out of that default with skipPermissions = false - a documented, supported thing to do (see the README's ci = { skipPermissions = false; } example) - which silently also gives up the box's sudo escape hatch as a side effect, with nothing anywhere saying so.

What I shipped

PR #727 documents this limitation everywhere someone would otherwise burn time trying to widen sudoers instead: the shipped AGENTS guide, the rendered Caddyfile comments, the codexFullAccess option doc, and the README's option table + security model. No behavior change.

What's still open

The issue also asks for "an equivalent safe reload path that works in Codex's execution sandbox." That's a real, undecided design question - e.g. a root-owned watcher that auto-reloads caddy on ~/sites/*.caddy changes (no sudo call needed at all, works uniformly for sandboxed codex AND everyone else), vs. some non-setuid IPC to a privileged helper, vs. just accepting that a workspace-write-sandboxed codex session has no privileged escape hatch, full stop. Each has real trade-offs (a watcher silently reloading a broken snippet vs. today's visible manual step being the main one). I didn't pick one and build it unilaterally since it's a security-relevant box-wide default for every deployment - let me know if you want this pursued as a follow-up and which direction, otherwise I'd suggest closing this once #727 lands and opening a narrower issue only if the auto-reload idea is worth building.

🤖 Generated with Claude Code

[defangdevs]

PR #727 merged (fixes the docs; leaving this open per the earlier comment for a decision on the privilege-escalation-free reload path).

[defangdevs]

Fresh reproduction from a real task: this also occurs when Codex is explicitly running in
the box-wide full-access mode, so the current diagnosis that it requires opting out with
skipPermissions = false is incomplete.

Evidence from the affected session:

$ cat /etc/codex/config.toml
approval_policy = "never"
sandbox_mode = "danger-full-access"

$ ps -o args= -p <pane-pid>
... codex -c approval_policy=never -c sandbox_mode=danger-full-access

$ stat -c '%U:%G %a %n' /run/wrappers/bin/sudo
nobody:nogroup 4511 /run/wrappers/bin/sudo

$ sudo -n /run/current-system/sw/bin/systemctl reload caddy.service
sudo: /nix/store/.../bin/sudo must be owned by uid 0 and have the setuid bit set

A plain tmux shell window created on the host from the same session/user saw the same wrapper
as root:root and successfully executed the allowlisted reload. The namespace boundary is
therefore specific to the tool-command execution surface despite the harness argv and system
config both saying danger-full-access.

This was not theoretical: exposing a Docker Compose preview required a Caddy reload, and the
agent had to create a temporary host tmux window to run the allowlisted command. The safe
non-setuid reload path proposed in this issue is still needed for the default full-access
Codex configuration, not only for explicitly sandboxed profiles.

Environment: agent-box 894a9aed3dbb7ee583d9c0470401f653235a813c, Codex session launched
with the explicit argv above.