## Summary
- leave the default contributor devcontainer on its lightweight
platform-only Docker runtime
- install bubblewrap in setuid mode only in the secure devcontainer
image for running Codex inside Docker
- add Docker run args to the secure profile for bubblewrap's required
capabilities
- use explicit `seccomp=unconfined` and `apparmor=unconfined` in the
secure profile instead of shipping a custom seccomp profile
- document that the relaxed Docker security options are scoped to the
secure profile
## Why
Docker's default seccomp profile blocks bubblewrap with `pivot_root:
Operation not permitted`, even when the container has `CAP_SYS_ADMIN`.
Docker's default AppArmor profile also blocks bubblewrap with `Failed to
make / slave: Permission denied`.
A custom seccomp profile works, but it is hard for customers to audit
and understand. Using Docker's standard `seccomp=unconfined` option is
clearer: the secure profile intentionally relaxes Docker's outer sandbox
just enough for Codex to construct its own bubblewrap/seccomp sandbox
inside the container. The default contributor profile does not get these
expanded runtime settings.
## Validation
- `sed '/\\/\\*/,/\\*\\//d' .devcontainer/devcontainer.json | jq empty`
- `jq empty .devcontainer/devcontainer.secure.json`
- `git diff --check`
- `docker build --platform=linux/arm64 -t
codex-devcontainer-bwrap-test-arm64 ./.devcontainer`
- `docker build --platform=linux/arm64 -f
.devcontainer/Dockerfile.secure -t
codex-devcontainer-secure-bwrap-test-arm64 .`
- interactive `docker run -it` smoke tests:
- verified non-root users `ubuntu` and `vscode`
- verified secure image `/usr/bin/bwrap` is setuid
- verified user/pid namespace, user/network namespace, and preserved-fd
`--ro-bind-data` bwrap commands
- reran secure-image smoke test with simplified `seccomp=unconfined`
setup:
- `bwrap-basic-ok`
- `bwrap-netns-ok`
- `codex-ok`
- ran Codex inside the secure image:
- `codex --version` -> `codex-cli 0.120.0`
- `codex sandbox linux --full-auto -- /bin/sh -lc '...'` -> exited 0 and
printed `codex-inner-ok`
Note: direct `bwrap --proc /proc` is still denied by this Docker
runtime, and Codex's existing proc-mount preflight fallback handles that
by retrying without `--proc`.
---------
Co-authored-by: Codex <noreply@openai.com>
## Description
Keeps the existing Codex contributor devcontainer in place and adds a
separate secure profile for customer use.
## What changed
- leaves `.devcontainer/devcontainer.json` and the contributor
`Dockerfile` aligned with `main`
- adds `.devcontainer/devcontainer.secure.json` and
`.devcontainer/Dockerfile.secure`
- adds secure-profile bootstrap scripts:
- `post_install.py`
- `post-start.sh`
- `init-firewall.sh`
- updates `.devcontainer/README.md` to explain when to use each path
## Secure profile behavior
The new secure profile is opt-in and is meant for running Codex in a
stricter project container:
- preinstalls the Codex CLI plus common build tools
- uses persistent volumes for Codex state, Cargo, Rustup, and GitHub
auth
- applies an allowlist-driven outbound firewall at startup
- blocks IPv6 by default so the allowlist cannot be bypassed via AAAA
routes
- keeps the stricter networking isolated from the default contributor
workflow
## Resulting behavior
- `devcontainer.json` remains the low-friction Codex contributor setup
- `devcontainer.secure.json` is the customer-facing secure option
- the repo supports both workflows without forcing the secure profile on
Codex contributors
