## 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
Users were running into issues with glibc mismatches on arm64 linux. In
the past, we did not provide a musl build for arm64 Linux because we had
trouble getting the openssl dependency to build correctly. Though today
I just tried the same trick in `Cargo.toml` that we were doing for
`x86_64-unknown-linux-musl` (using `openssl-sys` with `features =
["vendored"]`), so I'm not sure what problem we had in the past the
builds "just worked" today!
Though one tweak that did have to be made is that the integration tests
for Seccomp/Landlock empirically require longer timeouts on arm64 linux,
or at least on the `ubuntu-24.04-arm` GitHub Runner. As such, we change
the timeouts for arm64 in `codex-rs/linux-sandbox/tests/landlock.rs`.
Though in solving this problem, I decided I needed a turnkey solution
for testing the Linux build(s) from my Mac laptop, so this PR introduces
`.devcontainer/Dockerfile` and `.devcontainer/devcontainer.json` to
facilitate this. Detailed instructions are in `.devcontainer/README.md`.
We will update `dotslash-config.json` and other release-related scripts
in a follow-up PR.
