Problem:
The `aarch64-unknown-linux-musl` release build was failing at link time
with
`/usr/bin/ld: cannot find -lcap` while building binaries that
transitively pull
in `codex-linux-sandbox`.
Why this is the right fix:
`codex-linux-sandbox` compiles vendored bubblewrap and links `libcap`.
In the
musl jobs, we were installing distro `libcap-dev`, which provides
host/glibc
artifacts. That is not a valid source of target-compatible static libcap
for
musl cross-linking, so the fix is to produce a target-compatible libcap
inside
the musl tool bootstrap and point pkg-config at it.
This also closes the CI coverage gap that allowed this to slip through:
the
`rust-ci.yml` matrix did not exercise `aarch64-unknown-linux-musl` in
`release`
mode. Adding that target/profile combination to CI is the right
regression
barrier for this class of failure.
What changed:
- Updated `.github/scripts/install-musl-build-tools.sh` to install
tooling
needed to fetch/build libcap sources (`curl`, `xz-utils`, certs).
- Added deterministic libcap bootstrap in the musl tool root:
- download `libcap-2.75` from kernel.org
- verify SHA256
- build with the target musl compiler (`*-linux-musl-gcc`)
- stage `libcap.a` and headers under the target tool root
- generate a target-scoped `libcap.pc`
- Exported target `PKG_CONFIG_PATH` so builds resolve the staged musl
libcap
instead of host pkg-config/lib paths.
- Updated `.github/workflows/rust-ci.yml` to add a `release` matrix
entry for
`aarch64-unknown-linux-musl` on the ARM runner.
- Updated `.github/workflows/rust-ci.yml` to set
`CARGO_PROFILE_RELEASE_LTO=thin` for `release` matrix entries (and keep
`fat`
for non-release entries), matching the release-build tradeoff already
used in
`rust-release.yml` while reducing CI runtime.
Verification:
- Reproduced the original failure in CI-like containers:
- `aarch64-unknown-linux-musl` failed with `cannot find -lcap`.
- Verified the underlying mismatch by forcing host libcap into the link:
- link then failed with glibc-specific unresolved symbols
(`__isoc23_*`, `__*_chk`), confirming host libcap was unsuitable.
- Verified the fix in CI-like containers after this change:
- `cargo build -p codex-linux-sandbox --target
aarch64-unknown-linux-musl --release` -> pass
- `cargo build -p codex-linux-sandbox --target x86_64-unknown-linux-musl
--release` -> pass
- Triggered `rust-ci` on this branch and confirmed the new job appears:
- `Lint/Build — ubuntu-24.04-arm - aarch64-unknown-linux-musl (release)`
## Summary
This PR removes the temporary `CODEX_BWRAP_ENABLE_FFI` flag and makes
Linux builds always compile vendored bubblewrap support for
`codex-linux-sandbox`.
## Changes
- Removed `CODEX_BWRAP_ENABLE_FFI` gating from
`codex-rs/linux-sandbox/build.rs`.
- Linux builds now fail fast if vendored bubblewrap compilation fails
(instead of warning and continuing).
- Updated fallback/help text in
`codex-rs/linux-sandbox/src/vendored_bwrap.rs` to remove references to
`CODEX_BWRAP_ENABLE_FFI`.
- Removed `CODEX_BWRAP_ENABLE_FFI` env wiring from:
- `.github/workflows/rust-ci.yml`
- `.github/workflows/bazel.yml`
- `.github/workflows/rust-release.yml`
---------
Co-authored-by: David Zbarsky <zbarsky@openai.com>
This add a new crate, `codex-network-proxy`, a local network proxy
service used by Codex to enforce fine-grained network policy (domain
allow/deny) and to surface blocked network events for interactive
approvals.
- New crate: `codex-rs/network-proxy/` (`codex-network-proxy` binary +
library)
- Core capabilities:
- HTTP proxy support (including CONNECT tunneling)
- SOCKS5 proxy support (in the later PR)
- policy evaluation (allowed/denied domain lists; denylist wins;
wildcard support)
- small admin API for polling/reload/mode changes
- optional MITM support for HTTPS CONNECT to enforce “limited mode”
method restrictions (later PR)
Will follow up integration with codex in subsequent PRs.
## Testing
- `cd codex-rs && cargo build -p codex-network-proxy`
- `cd codex-rs && cargo run -p codex-network-proxy -- proxy`
Michael Bolin ·
viyatb-oai ·
Anton Panasenko ·
jif-oai ·
Ahmed Ibrahim ·