## Summary
CI is broken on main because our CI toolchain is trying to run 1.93.1
while our rust toolchain is locked at 1.93.0. I'm sure it's likely safe
to upgrade, but let's keep things stable for now.
## Testing
- [x] CI should hopefully pass
## Why
The `release` job in `.github/workflows/rust-release.yml` uploads
`files: dist/**` via `softprops/action-gh-release`. The downloaded
timing artifacts include multiple files with the same basename,
`cargo-timing.html` (one per target), which causes release asset
collisions/races and can fail with GitHub release-assets API `404 Not
Found` errors.
## What Changed
- Updated the existing cleanup step before `Create GitHub Release` to
remove all `cargo-timing.html` files from `dist/`.
- Removed any now-empty directories after deleting those timing files.
Relevant change:
-
daba003d32/.github/workflows/rust-release.yml (L423)
## Verification
- Confirmed from failing release logs that multiple `cargo-timing.html`
files were being included in `dist/**` and that the release step failed
while operating on duplicate-named assets.
- Verified the workflow now deletes those files before the release
upload step, so `cargo-timing.html` is no longer part of the release
asset set.
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)`
## Why
We want actionable build-hotspot data from CI so we can tune Rust
workflow performance (for example, target coverage, cache behavior, and
job shape) based on actual compile-time bottlenecks.
`cargo` timing reports are lightweight and provide a direct way to
inspect where compilation time is spent.
## What Changed
- Updated `.github/workflows/rust-release.yml` to run `cargo build` with
`--timings` and upload `target/**/cargo-timings/cargo-timing.html`.
- Updated `.github/workflows/rust-release-windows.yml` to run `cargo
build` with `--timings` and upload
`target/**/cargo-timings/cargo-timing.html`.
- Updated `.github/workflows/rust-ci.yml` to:
- run `cargo clippy` with `--timings`
- run `cargo nextest run` with `--timings` (stable-compatible)
- upload `target/**/cargo-timings/cargo-timing.html` artifacts for both
the clippy and nextest jobs
Artifacts are matrix-scoped via artifact names so timings can be
compared per target/profile.
## Verification
- Confirmed the net diff is limited to:
- `.github/workflows/rust-ci.yml`
- `.github/workflows/rust-release.yml`
- `.github/workflows/rust-release-windows.yml`
- Verified timing uploads are added immediately after the corresponding
timed commands in each workflow.
- Confirmed stable Cargo accepts plain `--timings` for the compile phase
(`cargo test --no-run --timings`) and generates
`target/cargo-timings/cargo-timing.html`.
- Ran VS Code diagnostics on modified workflow files; no new diagnostics
were introduced by these changes.
## 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>
## Why
Installing `zstd` via Chocolatey in
`.github/workflows/rust-release-windows.yml` has been taking about a
minute on Windows release runs. This adds avoidable latency to each
release job.
Using DotSlash removes that package-manager install step and pins the
exact binary we use for compression.
## What Changed
- Added `.github/workflows/zstd`, a DotSlash wrapper that fetches
`zstd-v1.5.7-win64.zip` with pinned size and digest.
- Updated `.github/workflows/rust-release-windows.yml` to:
- install DotSlash via `facebook/install-dotslash@v2`
- replace `zstd -T0 -19 ...` with
`${GITHUB_WORKSPACE}/.github/workflows/zstd -T0 -19 ...`
- `windows-aarch64` uses the same win64 upstream zstd artifact because
upstream releases currently publish `win32` and `win64` binaries.
## Verification
- Verified the workflow now resolves the DotSlash file from
`${GITHUB_WORKSPACE}` while the job runs with `working-directory:
codex-rs`.
- Ran VS Code diagnostics on changed files:
- `.github/workflows/rust-release-windows.yml`
- `.github/workflows/zstd`
## Why
`rust-release` cache restore has had very low practical value, while
cache save consistently costs significant time (usually adding ~3
minutes to the critical path of a release workflow).
From successful release-tag runs with cache steps (`289` runs total):
- Alpha tags: cache download averaged ~5s/run, cache upload averaged
~230s/run.
- Stable tags: cache download averaged ~5s/run, cache upload averaged
~227s/run.
- Windows release builds specifically: download ~2s/run vs upload
~169-170s/run.
Hard step-level signal from the same successful release-tag runs:
- Cache restore (`Run actions/cache`): `2,314` steps, total `1,515s`
(~0.65s/step).
- `95.3%` of restore steps finished in `<=1s`; `99.7%` finished in
`<=2s`; `0` steps took `>=10s`.
- Cache save (`Post Run actions/cache`): `2,314` steps, total `66,295s`
(~28.65s/step).
Run-level framing:
- Download total was `<=10s` in `288/289` runs (`99.7%`).
- Upload total was `>=120s` in `285/289` runs (`98.6%`).
The net effect is that release jobs are spending time uploading caches
that are rarely useful for subsequent runs.
## What Changed
- Removed the `actions/cache@v5` step from
`.github/workflows/rust-release.yml`.
- Removed the `actions/cache@v5` step from
`.github/workflows/rust-release-windows.yml`.
- Left build, signing, packaging, and publishing flow unchanged.
## Validation
- Queried historical `rust-release` run/job step timing and compared
cache download vs upload for alpha and stable release tags.
- Spot-checked release logs and observed repeated `Cache not found ...`
followed by `Cache saved ...` patterns.
This is in response to seeing this on BuildBuddy:
> There were tests whose specified size is too big. Use the
--test_verbose_timeout_warnings command line option to see which ones
these are.
I gave Codex the following bug report about the logic to report the
host's resources introduced in
https://github.com/openai/codex/pull/11488 and this PR is its proposed
fix.
The fix seems like an escaping issue, mostly.
---
The logic to print out the runner specs has an awk error on Mac:
```
Runner: GitHub Actions 1014936475
OS: macOS 15.7.3
Hardware model: VirtualMac2,1
CPU architecture: arm64
Logical CPUs: 5
Physical CPUs: 5
awk: syntax error at source line 1
context is
{printf >>> \ <<< "%.1f GiB\\n\", $1 / 1024 / 1024 / 1024}
awk: illegal statement at source line 1
Total RAM:
Disk usage:
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk3s5 320Gi 237Gi 64Gi 79% 2.0M 671M 0% /System/Volumes/Data
```
as well as Linux:
```
Runner: GitHub Actions 1014936469
OS: Linux runnervmwffz4 6.11.0-1018-azure #18~24.04.1-Ubuntu SMP Sat Jun 28 04:46:03 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
awk: cmd. line:1: /Model name/ {gsub(/^[ \t]+/,\"\",$2); print $2; exit}
awk: cmd. line:1: ^ backslash not last character on line
CPU model:
Logical CPUs: 4
awk: cmd. line:1: /MemTotal/ {printf \"%.1f GiB\\n\", $2 / 1024 / 1024}
awk: cmd. line:1: ^ backslash not last character on line
Total RAM:
Disk usage:
Filesystem Size Used Avail Use% Mounted on
/dev/root 72G 50G 22G 70% /
```
Windows release builds were compiling and linking four release binaries
on a single runner, which slowed the release pipeline. The
Windows-specific logic also made `rust-release.yml` harder to read and
maintain.
## What Changed
- Extracted Windows release logic into a reusable workflow at
`.github/workflows/rust-release-windows.yml`.
- Updated `.github/workflows/rust-release.yml` to call the reusable
Windows workflow via `workflow_call`.
- Parallelized Windows binary builds with one 4-entry matrix over two
targets (`x86_64-pc-windows-msvc`, `aarch64-pc-windows-msvc`) and two
bundles (`primary`, `helpers`).
- Kept signing centralized per target by downloading both prebuilt
bundles and signing all four executables together.
- Preserved final release artifact behavior and filtered intermediate
`windows-binaries*` artifacts out of the published release asset set.
Windows release builds in `.github/workflows/rust-release.yml` were
still using GitHub-hosted `windows-latest` and `windows-11-arm` runners.
This change aligns release builds with the faster dedicated Codex runner
pool already used in CI, and adds machine-spec logging at startup so
runner capacity (CPU/RAM/disk) is visible in build logs.
## What Changed
- Updated the `build` job to support matrix entries that provide a full
`runs_on` object:
- `runs-on: ${{ matrix.runs_on || matrix.runner }}`
- Switched Windows release matrix entries to Codex runners:
- `windows-latest` -> `windows-x64` with:
- `group: codex-runners`
- `labels: codex-windows-x64`
- `windows-11-arm` -> `windows-arm64` with:
- `group: codex-runners`
- `labels: codex-windows-arm64`
- Updated the ARM-specific zstd install condition to match the new
runner id:
- `matrix.runner == 'windows-arm64'`
- Added early platform-specific runner diagnostics steps
(Linux/macOS/Windows) that print OS, CPU, logical CPU count, total RAM,
and disk usage.
## Summary
- detect whether BUILDBUDDY_API_KEY is present in Bazel CI
- keep existing remote BuildBuddy path when key is available
- add a local fallback path for fork PRs without secrets by clearing
remote cache/executor/BES endpoints
- document each fallback flag inline with links to Bazel docs
## Testing
- ruby -e 'require "yaml";
YAML.load_file(".github/workflows/bazel.yml"); puts "ok"'
- verified Bazel docs/flag references used in workflow comments
We are looking to speed up build times for alpha releases, but we do not
want to completely compromise on runtime performance by shipping debug
builds. This PR changes our CI so that alpha releases build with
`lto="thin"` instead of `lto="fat"`.
Specifically, this change keeps `[profile.release] lto = "fat"` as the
default in `Cargo.toml`, but overrides LTO in CI using
`CARGO_PROFILE_RELEASE_LTO`:
- `rust-release.yml`: use `thin` for `-alpha` tags, otherwise `fat`
- `shell-tool-mcp.yml`: use `thin` for `-alpha` versions, otherwise
`fat`
Tradeoffs:
- Alpha binaries may be somewhat larger and/or slightly slower than
fat-LTO builds
- LTO policy now lives in workflow logic for two pipelines, so
consistency must be maintained across both files
Note `CARGO_PROFILE_<name>_LTO` is documented on
https://doc.rust-lang.org/cargo/reference/environment-variables.html#configuration-environment-variables.
https://github.com/openai/codex/pull/11318 introduced logic to publish
platform artifacts as separate npm packages (for example,
`@openai/codex-darwin-arm64`, `@openai/codex-linux-x64`, etc.). That
requires provisioning and maintaining multiple package entries in npm,
which we want to avoid.
We still need to keep the package-size mitigation (platform-specific
payloads), but we want that layout to live under a single npm package
namespace (`@openai/codex`) using dist-tags.
We also need to preserve pre-release workflows where users install
`@openai/codex@alpha` and get platform-appropriate binaries.
Additionally, we want GitHub Release assets to group Codex npm tarballs
together, so platform tarballs should follow the same `codex-npm-*`
filename prefix as the main Codex tarball.
## Release Strategy (New Scheme)
We publish **one npm package name for Codex binaries** (`@openai/codex`)
and use **dist-tags** to select platform-specific payloads. This avoids
creating separate platform package names while keeping the package size
split by platform.
### What gets published
#### Mainline release (`x.y.z`)
- `@openai/codex@latest` (meta package)
- `@openai/codex@darwin-arm64`
- `@openai/codex@darwin-x64`
- `@openai/codex@linux-arm64`
- `@openai/codex@linux-x64`
- `@openai/codex@win32-arm64`
- `@openai/codex@win32-x64`
- `@openai/codex-responses-api-proxy@latest`
- `@openai/codex-sdk@latest`
#### Alpha release (`x.y.z-alpha.N`)
- `@openai/codex@alpha` (meta package)
- `@openai/codex@alpha-darwin-arm64`
- `@openai/codex@alpha-darwin-x64`
- `@openai/codex@alpha-linux-arm64`
- `@openai/codex@alpha-linux-x64`
- `@openai/codex@alpha-win32-arm64`
- `@openai/codex@alpha-win32-x64`
- `@openai/codex-responses-api-proxy@alpha`
- `@openai/codex-sdk@alpha`
As an example, the `package.json` for `@openai/codex@alpha` (using
`0.99.0-alpha.17` as the `version`) would be:
```
{
"name": "@openai/codex",
"version": "0.99.0-alpha.17",
"license": "Apache-2.0",
"bin": {
"codex": "bin/codex.js"
},
"type": "module",
"engines": {
"node": ">=16"
},
"files": [
"bin"
],
"repository": {
"type": "git",
"url": "git+https://github.com/openai/codex.git",
"directory": "codex-cli"
},
"packageManager": "pnpm@10.28.2+sha512.41872f037ad22f7348e3b1debbaf7e867cfd448f2726d9cf74c08f19507c31d2c8e7a11525b983febc2df640b5438dee6023ebb1f84ed43cc2d654d2bc326264",
"optionalDependencies": {
"@openai/codex-linux-x64": "npm:@openai/codex@0.99.0-alpha.17-linux-x64",
"@openai/codex-linux-arm64": "npm:@openai/codex@0.99.0-alpha.17-linux-arm64",
"@openai/codex-darwin-x64": "npm:@openai/codex@0.99.0-alpha.17-darwin-x64",
"@openai/codex-darwin-arm64": "npm:@openai/codex@0.99.0-alpha.17-darwin-arm64",
"@openai/codex-win32-x64": "npm:@openai/codex@0.99.0-alpha.17-win32-x64",
"@openai/codex-win32-arm64": "npm:@openai/codex@0.99.0-alpha.17-win32-arm64"
}
}
```
Note that the keys in `optionalDependencies` have "clean" names, but the
values have the tag embedded.
### Important note
**Note:** Because we never created the new platform package names on npm
(for example,
`@openai/codex-darwin-arm64`) since #11318 landed, there are no extra
npm packages to clean up.
## What changed
### 1. Stage platform tarballs as `@openai/codex` with platform-specific
versions
File: `codex-cli/scripts/build_npm_package.py`
- Added `CODEX_NPM_NAME = "@openai/codex"` and platform metadata
`npm_tag` values:
- `darwin-arm64`, `darwin-x64`, `linux-arm64`, `linux-x64`,
`win32-arm64`, `win32-x64`
- For platform package staging (`codex-<platform>` inputs), switched
generated `package.json` from:
- `name = @openai/codex-<platform>`
to:
- `name = @openai/codex`
- Added `compute_platform_package_version(version, platform_tag)` so
platform tarballs have unique
versions (`<release-version>-<platform-tag>`), which is required because
npm forbids re-publishing
the same `name@version`.
### 2. Point meta package optional dependencies at dist-tags on
`@openai/codex`
File: `codex-cli/scripts/build_npm_package.py`
- Updated `optionalDependencies` generation for the main `codex` package
to use npm alias syntax:
- key remains alias package name (for example,
`@openai/codex-darwin-arm64`) so runtime lookup behavior is unchanged
- value now resolves to `@openai/codex` by dist-tag
- Stable releases emit tags like `npm:@openai/codex@darwin-arm64`.
- Alpha releases (`x.y.z-alpha.N`) emit tags like
`npm:@openai/codex@alpha-darwin-arm64`.
### 3. Publish with per-tarball dist-tags in release CI
File: `.github/workflows/rust-release.yml`
- Reworked npm publish logic to derive the publish tag per tarball
filename:
- platform tarballs publish with `<platform>` tags for stable releases
- platform tarballs publish with `alpha-<platform>` tags for alpha
releases
- top-level tarballs (`codex`, `codex-responses-api-proxy`, `codex-sdk`)
continue using
the existing channel tag policy (`latest` implicit for stable, `alpha`
for alpha)
- Added fail-fast behavior for unexpected tarball names to avoid silent
mispublishes.
### 4. Normalize Codex platform tarball filenames for GitHub Release
grouping
Files: `scripts/stage_npm_packages.py`,
`.github/workflows/rust-release.yml`
- Renamed staged platform tarball filenames from:
- `codex-linux-<arch>-npm-<version>.tgz`
- `codex-darwin-<arch>-npm-<version>.tgz`
- `codex-win32-<arch>-npm-<version>.tgz`
- To:
- `codex-npm-linux-<arch>-<version>.tgz`
- `codex-npm-darwin-<arch>-<version>.tgz`
- `codex-npm-win32-<arch>-<version>.tgz`
This keeps all Codex npm artifacts grouped under a common `codex-npm-`
prefix in GitHub Releases.
### 5. Documentation update
File: `codex-cli/scripts/README.md`
- Updated staging docs to clarify that platform-native variants are
published as dist-tagged
`@openai/codex` artifacts rather than separate npm package names.
## Resulting behavior
- Mainline release:
- `@openai/codex@latest` resolves the meta package
- meta package optional dependencies resolve
`@openai/codex@<platform-tag>`
- Alpha release:
- users can continue installing `@openai/codex@alpha`
- alpha meta package optional dependencies resolve
`@openai/codex@alpha-<platform-tag>`
- Release assets:
- Codex npm tarballs share `codex-npm-` prefix for cleaner grouping in
GitHub Releases
This preserves platform-specific payload distribution while avoiding
separate npm package names and
improves release-asset discoverability.
## Validation notes
- Verified staged `package.json` output for stable and alpha meta
packages includes expected alias targets.
- Verified staged platform package manifests are `name=@openai/codex`
with unique platform-suffixed versions.
- Verified publish tag derivation maps renamed platform tarballs to
expected stable and alpha dist-tags.
Given that we have https://github.com/openai/codex/pull/10977, the
existing "Verify config schema fixture" step seems unnecessary. Further,
because it happens as part of the `tag-check` job (which is meant to be
fast), it slows down the entire build process because it delays the more
expensive steps from starting.
## Summary
This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
curent Linux sandbox path relies on in-process restrictions (including
Landlock). Bubblewrap gives us a more uniform filesystem isolation
model, especially explicit writable roots with the option to make some
directories read-only and granular network controls.
This is behind a feature flag so we can validate behavior safely before
making it the default.
- Added temporary rollout flag:
- `features.use_linux_sandbox_bwrap`
- Preserved existing default path when the flag is off.
- In Bubblewrap mode:
- Added internal retry without /proc when /proc mount is not permitted
by the host/container.
Currently, our `npm publish` logic is failing.
There were a number of things that were merged recently that seemed to
contribute to this situation, though I think we have fixed most of them,
but this one stands out:
https://github.com/openai/codex/pull/10115
As best I can tell, we tried to fix the pnpm version to a specific hash,
but we did not do it consistently (though `shell-tool-mcp/package.json`
had it specified twice...), so for this PR, I ran:
```
$ git ls-files | grep package.json
codex-cli/package.json
codex-rs/responses-api-proxy/npm/package.json
package.json
sdk/typescript/package.json
shell-tool-mcp/package.json
```
and ensured that all of them now have this line:
```json
"packageManager": "pnpm@10.28.2+sha512.41872f037ad22f7348e3b1debbaf7e867cfd448f2726d9cf74c08f19507c31d2c8e7a11525b983febc2df640b5438dee6023ebb1f84ed43cc2d654d2bc326264"
```
I also went and deleted all of the `corepack` stuff that was added by
https://github.com/openai/codex/pull/10115.
If someone can explain why we need it and verify it does not break `npm
publish`, then we can bring it back.
This updates the CI workflows for shell-tool-mcp to use the pnpm version
from package.json and print it in the build for verification.
I have read the CLA Document and I hereby sign the CLA
I needed to upgrade bazel one to get gnullvm artifacts and then noticed
monorepo had drifted forward. They should move in lockstep. Also 1.93
already shipped so we can try that instead.
Add a `.sqlite` database to be used to store rollout metatdata (and
later logs)
This PR is phase 1:
* Add the database and the required infrastructure
* Add a backfill of the database
* Persist the newly created rollout both in files and in the DB
* When we need to get metadata or a rollout, consider the `JSONL` as the
source of truth but compare the results with the DB and show any errors
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`
## Summary
Upgrade GitHub Actions to their latest versions to ensure compatibility
with Node 24, as Node 20 will reach end-of-life in April 2026.
## Changes
| Action | Old Version(s) | New Version | Release | Files |
|--------|---------------|-------------|---------|-------|
| `actions/cache` |
[`v4`](https://github.com/actions/cache/releases/tag/v4) |
[`v5`](https://github.com/actions/cache/releases/tag/v5) |
[Release](https://github.com/actions/cache/releases/tag/v5) | bazel.yml
|
## Context
Per [GitHub's
announcement](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/),
Node 20 is being deprecated and runners will begin using Node 24 by
default starting March 4th, 2026.
### Why this matters
- **Node 20 EOL**: April 2026
- **Node 24 default**: March 4th, 2026
- **Action**: Update to latest action versions that support Node 24
### Security Note
Actions that were previously pinned to commit SHAs remain pinned to SHAs
(updated to the latest release SHA) to maintain the security benefits of
immutable references.
### Testing
These changes only affect CI/CD workflow configurations and should not
impact application functionality. The workflows should be tested by
running them on a branch before merging.
Signed-off-by: Salman Muin Kayser Chishti <13schishti@gmail.com>
Follow up to #8956; publish schema on new release to stable URL.
Also canonicalize schema (sort keys) when writing. This avoids reliance
on default `schema_rs` behavior and makes the schema easier to read.
As explained in `codex-rs/core/BUILD.bazel`, including the repo's own
`AGENTS.md` is a hack to get some tests passing. We should fix this
properly, but I wanted to put stake in the ground ASAP to get `just
bazel-remote-test` working and then add a job to `bazel.yml` to ensure
it keeps working.
This PR configures Codex CLI so it can be built with
[Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
includes configuration so that remote builds can be done using
[BuildBuddy](https://www.buildbuddy.io).
If you are familiar with Bazel, things should work as you expect, e.g.,
run `bazel test //... --keep-going` to run all the tests in the repo,
but we have also added some new aliases in the `justfile` for
convenience:
- `just bazel-test` to run tests locally
- `just bazel-remote-test` to run tests remotely (currently, the remote
build is for x86_64 Linux regardless of your host platform). Note we are
currently seeing the following test failures in the remote build, so we
still need to figure out what is happening here:
```
failures:
suite::compact::manual_compact_twice_preserves_latest_user_messages
suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
```
- `just build-for-release` to build release binaries for all
platforms/architectures remotely
To setup remote execution:
- [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
employees should also request org access at
https://openai.buildbuddy.io/join/ with their `@openai.com` email
address.)
- [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
`~/.bazelrc` (add the line `build
--remote_header=x-buildbuddy-api-key=YOUR_KEY`)
- Use `--config=remote` in your `bazel` invocations (or add `common
--config=remote` to your `~/.bazelrc`, or use the `just` commands)
## CI
In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
(we are working on supporting Windows, but that is not ready yet). Note
that the failures we are seeing in `just bazel-remote-test` do not occur
on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
is green right now.
The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
that macOS CI jobs build _remotely_ on Linux hosts (using the
`docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
root `BUILD.bazel`) using cross-compilation to build the macOS
artifacts. Then these artifacts are downloaded locally to GitHub's macOS
runner so the tests can be executed natively. This is the relevant
config that enables this:
```
common:macos --config=remote
common:macos --strategy=remote
common:macos --strategy=TestRunner=darwin-sandbox,local
```
Because of the remote caching benefits we get from BuildBuddy, these new
CI jobs can be extremely fast! For example, consider these two jobs that
ran all the tests on Linux x86_64:
- Bazel 1m37s
https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
- Cargo 9m20s
https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
For now, we will continue to run both the Bazel and Cargo jobs for PRs,
but once we add support for Windows and running Clippy, we should be
able to cutover to using Bazel exclusively for PRs, which should still
speed things up considerably. We will probably continue to run the Cargo
jobs post-merge for commits that land on `main` as a sanity check.
Release builds will also continue to be done by Cargo for now.
Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
Earlier attempt to add support for Buck2, now abandoned:
https://github.com/openai/codex/pull/8504
---------
Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
Co-authored-by: Michael Bolin <mbolin@openai.com>
