Linux sandbox setup fails silently in hardened containers: codex exec exits 0, no command runs, no operator-visible error

What version of Codex CLI is running?

codex-cli 0.153.3

(official GitHub release tarball codex-x86_64-unknown-linux-musl.tar.gz)

What subscription do you have?

ChatGPT Pro 20x

Which model were you using?

any model — this failure is independent of the model

For this repro we drove codex exec against a local deterministic scripted model (a loopback endpoint speaking the model API), because the test target is the pre-tool-use hook / sandbox execution path, not model behavior. The sandbox setup failure occurs before/independently of any model response handling: the same silent failure happens with any model (OpenAI-hosted or local), since the exec tool's sandbox setup fails inside the container regardless of which model issued the command.

What platform is your computer?

Linux x86_64 (container: non-root uid 10001, --cap-drop ALL, --security-opt no-new-privileges, no system bubblewrap)
Host: Linux 6.x x86_64

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

Not applicable — the failure reproduces with the non-interactive `codex exec` (no TTY required); no multiplexer in use.

Codex doctor report

not available

(0.153.3 codex doctor reports install/config/auth/terminal/MCP/network/state; it does not cover sandbox backend viability — the failing component in this report. Happy to paste doctor --json output if it would help anyway.)

What issue are you seeing?

On Linux, when neither the system nor the bundled bubblewrap can run — typical in hardened containers that deny user namespaces and mount syscalls (--cap-drop ALL, no-new-privileges, non-root user) — codex exec with --sandbox workspace-write (and --sandbox read-only) fails to execute every shell command silently:

• the model receives the tool call, but no command ever runs and no filesystem effect occurs;
• the sandbox setup failure is fed back to the model as tool-level feedback that is not shown as an operator-facing error;
• codex exec still exits 0, so CI/automation and the human operator have no signal that anything failed.

The only hint is a startup warning saying Codex "will use the bundled bubblewrap in the meantime" — which is misleading in exactly these environments, because the bundled bubblewrap then fails too (it needs the same kernel privileges the container denies).

For anyone running Codex in CI or a restricted container, this is a silent no-op failure: the run "succeeds" while the agent actually accomplished nothing.

What steps can reproduce the bug?

1. Start a hardened container without bubblewrap and without namespace/mount privileges:

   docker run --rm -it \
     --user 10001:10001 \
     --cap-drop ALL \
     --security-opt no-new-privileges \
     <minimal-linux-image> bash
   

2. Install codex-cli 0.153.3 from the official GitHub release tarball and authenticate as usual.

3. Run a trivial write task non-interactively:

   mkdir -p /tmp/work && cd /tmp/work
   codex exec --sandbox workspace-write --skip-git-repo-check \
     "Create a file named hello.txt containing the word hi"
   echo "exit=$?"
   ls -l hello.txt
   

4. Repeat with --sandbox read-only and any command-bearing prompt; same result.

(If your model needs an explicit approval setting, --ask-for-approval never matches the configuration used.)

What is the expected behavior?

• If the sandbox backend cannot be set up, the failure should be operator-visible: a clear error on stderr identifying the failed sandbox setup, and a non-zero exit code for codex exec (or at minimum a prominent, non-model-only failure marker in the run output).
• The startup warning should not promise "Codex will use the bundled bubblewrap in the meantime" in environments where the bundled bubblewrap cannot work either (same user-namespace/mount requirements); it should say the bundled fallback still requires those privileges.

Actual behavior

• Startup prints the missing-bubblewrap warning (exact text observed):

  Codex could not find bubblewrap on PATH. Install bubblewrap with your OS package manager. See the sandbox prerequisites: https://developers.openai.com/codex/concepts/sandboxing#prerequisites. Codex will use the bundled bubblewrap in the meantime.

• The model receives the exec tool call, but no command_execution event ever fires and no filesystem effect occurs.

• The sandbox setup failure reaches only the model (as tool-call feedback); it is not rendered as an error to the operator.

• codex exec exits 0.

Additional information

• Measured on codex-cli 0.153.3 (official release tarball, Linux x86_64) inside the container described above; identical commands succeed outside the container.
• Observed via: exit code (0), missing expected file, absence of command-execution events in the session, and the absence of any operator-facing error text.
• The quoted warning string matches MISSING_BWRAP_WARNING in codex-rs/sandboxing/src/bwrap.rs at tag rust-v0.153.3. The bundled-bubblewrap launcher (codex-rs/linux-sandbox/src/bundled_bwrap.rs) exists at the same tag; why the bundled path fails in this container is our inference (it needs the same namespace/mount privileges the container denies), not something we verified in a debugger.
• Not tried: danger-full-access (out of scope for our usage), interactive TUI behavior in the same container.

Related issues (searched 2026-09-17)

• #23762 — "write only sandbox doesn't work inside a container" (open, podman; user sees a visible retry prompt, unlike our silent exec case)
• #35547 — "Linux sandbox lacks an actionable diagnostic when bwrap is blocked and Landlock is unavailable" (open; errors are shown there — low-level bwrap error and Landlock panic — so the diagnostic-quality angle overlaps, the silent exit-0 exec angle does not)
• #14976 — "Bubblewrap sandbox fails inside container for commands on bind-mounted host paths" (closed)
• #14794 — "VS Code Codex extension sandbox makes writable devcontainer workspace appear read-only in Linux" (open)
• #30691 — "bubblewrap is install but codex-cli alway say 'Codex could not find bubblewrap on PATH.'" (open)
• #25404 — "False positive 'Could not find bubblewrap on PATH' warning on Ubuntu 22.04 when bwrap is present and successfully executed" (open)
• #34723 — "Codex CLI incorrectly reports bubblewrap missing even when it is installed and available on PATH" (open)
• #44329 — "Codex CLI (and VSCode extension) sandbox unable to handle /proc mounting failures" (open)
• #44304 — "Codex 0.153.4 fails to recognize the expected /proc mount failure when using bubblewrap 0.12.0" (open)
• #24873 — "Codex Desktop WSL sandbox cannot find system bwrap; legacy Landlock fallback panics with permission profiles" (open)

Searches run: "bubblewrap", "sandbox container silent", "workspace-write container", "sandbox silently", "exec sandbox fails exit 0", "sandbox setup failure model", "command_execution event missing", "bundled bubblewrap fails container", "codex exec no command executed sandbox container". No existing issue describes the silent (exit 0, no operator-visible error) non-interactive failure mode in restricted containers.

Start with MISSING_BWRAP_WARNING in codex-rs/sandboxing/src/bwrap.rs and the bundled-bubblewrap launcher in codex-rs/linux-sandbox/src/bundled_bwrap.rs. Reproduce the hardened-container command from the issue and trace the codex exec sandbox setup and tool-feedback path. Done means sandbox setup failures are operator-visible, return a non-zero status, and the fallback warning accurately describes its prerequisites.