## Summary
This PR hardens package-manager usage across the repo to reduce
dependency supply-chain risk. It also removes the stale `codex-cli`
Docker path, which was already broken on `main`, instead of keeping a
bitrotted container workflow alive.
## What changed
- Updated pnpm package manager pins and workspace install settings.
- Removed stale `codex-cli` Docker assets instead of trying to keep a
broken local container path alive.
- Added uv settings and lockfiles for the Python SDK packages.
- Updated Python SDK setup docs to use `uv sync`.
## Why
This is primarily a security hardening change. It reduces
package-install and supply-chain risk by ensuring dependency installs go
through pinned package managers, committed lockfiles, release-age
settings, and reviewed build-script controls.
For `codex-cli`, the right follow-up was to remove the local Docker path
rather than keep patching it:
- `codex-cli/Dockerfile` installed `codex.tgz` with `npm install -g`,
which bypassed the repo lockfile and age-gated pnpm settings.
- The local `codex-cli/scripts/build_container.sh` helper was already
broken on `main`: it called `pnpm run build`, but
`codex-cli/package.json` does not define a `build` script.
- The container path itself had bitrotted enough that keeping it would
require extra packaging-specific behavior that was not otherwise needed
by the repo.
## Gaps addressed
- Global npm installs bypassed the repo lockfile in Docker and CLI
reinstall paths, including `codex-cli/Dockerfile` and
`codex-cli/bin/codex.js`.
- CI and Docker pnpm installs used `--frozen-lockfile`, but the repo was
missing stricter pnpm workspace settings for dependency build scripts.
- Python SDK projects had `pyproject.toml` metadata but no committed
`uv.lock` coverage or uv age/index settings in `sdk/python` and
`sdk/python-runtime`.
- The secure devcontainer install path used npm/global install behavior
without a local locked package-manager boundary.
- The local `codex-cli` Docker helper was already broken on `main`, so
this PR removes that stale Docker path instead of preserving a broken
surface.
- pnpm was already pinned, but not to the current repo-wide pnpm version
target.
## Verification
- `pnpm install --frozen-lockfile`
- `.devcontainer/codex-install`: `pnpm install --prod --frozen-lockfile`
- `.devcontainer/codex-install`: `./node_modules/.bin/codex --version`
- `sdk/python`: `uv lock --check`, `uv sync --locked --all-extras
--dry-run`, `uv build`
- `sdk/python-runtime`: `uv lock --check`, `uv sync --locked --dry-run`,
`uv build --wheel`
- `pnpm -r --filter ./sdk/typescript run build`
- `pnpm -r --filter ./sdk/typescript run lint`
- `pnpm -r --filter ./sdk/typescript run test`
- `node --check codex-cli/bin/codex.js`
- `docker build -f .devcontainer/Dockerfile.secure -t codex-secure-test
.`
- `cargo build -p codex-cli`
- repo-wide package-manager audit
## 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
I mainly use the devcontainer to be able to run `cargo clippy --tests`
locally for Linux.
We still need to make it possible to run clippy from Bazel so I don't
need to do this!
Apparently `just` was added to `apt` in Ubuntu 24, so this required
updating the Ubuntu version in the `Dockerfile` to make it so we could
simply `apt install just`.
Though then that caused a conflict with the custom `dev` user we were
using, though the end result seems simpler since now we just use the
default `ubuntu` user provided by Ubuntu 24.
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.
