Adam Perry @ OpenAI
9e3d5f29e2
## Why PR #25905 intentionally adds a failing `codex-core` unit test, but its [Bazel test on Windows check](https://github.com/openai/codex/actions/runs/26837526950/job/79135369259) passed. That shows the Bazel configuration introduced by #25156 is not behaving as expected, so revert it while the configuration can be investigated separately. ## What changed Revert #25156 in full, restoring the previous Bazel remote configuration, CI scripts, workflows, `rusty_v8` handling, and documentation. This removes the shared BuildBuddy wrapper and its tests. ## Validation Not run locally; this exact revert was prioritized for a fast rollback.
2.7 KiB
Bazel in codex-rs
This repository uses Bazel to build the Rust workspace under codex-rs.
Cargo remains the source of truth for crates and features, while Bazel
provides hermetic builds, toolchains, and cross-platform artifacts.
As of 1/9/2026, this setup is still experimental as we stabilize it.
High-level layout
../MODULE.bazeldefines Bazel dependencies and Rust toolchains.rules_rsimports third-party crates fromcodex-rs/Cargo.tomlandcodex-rs/Cargo.lockviacrate.from_cargo(...)and exposes them under@crates.../defs.bzlprovidescodex_rust_crate, which wrapsrust_library,rust_binary, andrust_testso Bazel targets line up with Cargo conventions. It provides a sane set of defaults that work for most first-party crates, but may need tweaks in some cases.- Each crate in
codex-rs/*/BUILD.bazeltypically usescodex_rust_crateand makes some adjustments if the crate needs additional compile-time or runtime data, or other customizations.
Evolving the setup
When you add or change Rust dependencies, update the Cargo.toml/Cargo.lock as normal. Then refresh the Bzlmod lockfile from the repo root:
just bazel-lock-update
This runs bazel mod deps --lockfile_mode=update and updates MODULE.bazel.lock if needed.
Commit the lockfile changes along with your Cargo lockfile update.
To verify lockfile alignment locally (the same check CI runs), use:
just bazel-lock-check
In some cases, an upstream crate may need a patch or a crate.annotation in ../MODULE.bzl
to have it build in Bazel's sandbox or make it cross-compilation-friendly. If you see issues,
feel free to ping zbarsky or mbolin.
When you add a new crate or binary:
- Add it to the Cargo workspace as usual.
- Create a
BUILD.bazelthat callscodex_rust_crate(see nearby crates for examples). - If a dependency needs special handling (compile/runtime data, additional binaries
for integration tests, env vars, etc) you may need to adjust the parameters to
codex_rust_crateto configure it. One common customization is settingtest_tags = ["no-sandbox]to run the test unsandboxed. Prefer to avoid it, but it is necessary in some cases such as when the test itself uses Seatbelt (the sandbox does as well, and it cannot be nested). To limit the blast radius, consider isolating such tests to a separate crate.
If you see build issue and are not sure how to apply the proper customizations, feel free to ping zbarsky or mbolin.
References
- Bazel overview: https://bazel.build/
- Bzlmod (module system): https://bazel.build/external/overview
- rules_rust: https://github.com/bazelbuild/rules_rust
- rules_rs: https://github.com/bazelbuild/rules_rs