feat: add support for building with Bazel #8875

zbarsky-openai · 2026-01-08T00:51:44Z

This PR configures Codex CLI so it can be built with Bazel in addition to Cargo. The .bazelrc includes configuration so that remote builds can be done using BuildBuddy.

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 (OpenAI employees should also request org access at https://openai.buildbuddy.io/join/ with their @openai.com email address.)
Copy your API key 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:

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: #8832
Earlier attempt to add support for Buck2, now abandoned: #8504

github-actions · 2026-01-08T01:24:37Z

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

…8879) To support Bazelification in #8875, this PR introduces a new `find_resource!` macro that we use in place of our existing logic in tests that looks for resources relative to the compile-time `CARGO_MANIFEST_DIR` env var. To make this work, we plan to add the following to all `rust_library()` and `rust_test()` Bazel rules in the project: ``` rustc_env = { "BAZEL_PACKAGE": native.package_name(), }, ``` Our new `find_resource!` macro reads this value via `option_env!("BAZEL_PACKAGE")` so that the Bazel package _of the code using `find_resource!`_ is injected into the code expanded from the macro. (If `find_resource()` were a function, then `option_env!("BAZEL_PACKAGE")` would always be `codex-rs/utils/cargo-bin`, which is not what we want.) Note we only consider the `BAZEL_PACKAGE` value when the `RUNFILES_DIR` environment variable is set at runtime, indicating that the test is being run by Bazel. In this case, we have to concatenate the runtime `RUNFILES_DIR` with the compile-time `BAZEL_PACKAGE` value to build the path to the resource. In testing this change, I discovered one funky edge case in `codex-rs/exec-server/tests/common/lib.rs` where we have to _normalize_ (but not canonicalize!) the result from `find_resource!` because the path contains a `common/..` component that does not exist on disk when the test is run under Bazel, so it must be semantically normalized using the [`path-absolutize`](https://crates.io/crates/path-absolutize) crate before it is passed to `dotslash fetch`. Because this new behavior may be non-obvious, this PR also updates `AGENTS.md` to make humans/Codex aware that this API is preferred.

This helps prepare us for Bazel builds: #8875.

…8887) This eliminates our dependency on the `escargot` crate and better prepares us for Bazel builds: #8875.

codex-rs/core/src/shell_snapshot.rs

.gitignore

bolinfest · 2026-01-08T16:31:03Z

codex-rs/core/tests/suite/prompt_caching.rs

@@ -1,6 +1,8 @@
 #![allow(clippy::unwrap_used)]

+use codex_apply_patch::APPLY_PATCH_TOOL_INSTRUCTIONS;


Will go away once #8914 is in.

…ssues (#8932) I have seen this test flake out sometimes when running the macOS build using Bazel in CI: #8875. Perhaps Bazel runs with greater parallelism, inducing a heavier load, causing an issue?

…t_rule() test (#8931) Because the path to `git` is used to construct `elicitations_to_accept`, we need to ensure that we resolve which `git` to use the same way our Bash process will: https://github.com/openai/codex/blob/c9c65606852c0cda9d983b4917359a0826a4b7f0/codex-rs/exec-server/tests/suite/accept_elicitation.rs#L59-L69 This fixes an issue when running the test on macOS using Bazel (#8875) where the login shell chose `/opt/homebrew/bin/git` whereas the non-login shell chose `/usr/bin/git`.

This seems to be necessary to get the Bazel builds on ARM Linux to go green on #8875. I don't feel great about timeout-whack-a-mole, but we're still learning here...

.github/workflows/Dockerfile.bazel

zbarsky-openai · 2026-01-09T02:15:22Z

.github/workflows/Dockerfile.bazel

+RUN apt-get update && \
+    apt-get install -y --no-install-recommends \
+    build-essential curl git python3 ca-certificates \
+    pkg-config clang musl-tools libssl-dev just && \


don't need libssl-dev, it comes from bazel and is built hermetically :)

.github/workflows/Dockerfile.bazel

…8879) To support Bazelification in #8875, this PR introduces a new `find_resource!` macro that we use in place of our existing logic in tests that looks for resources relative to the compile-time `CARGO_MANIFEST_DIR` env var. To make this work, we plan to add the following to all `rust_library()` and `rust_test()` Bazel rules in the project: ``` rustc_env = { "BAZEL_PACKAGE": native.package_name(), }, ``` Our new `find_resource!` macro reads this value via `option_env!("BAZEL_PACKAGE")` so that the Bazel package _of the code using `find_resource!`_ is injected into the code expanded from the macro. (If `find_resource()` were a function, then `option_env!("BAZEL_PACKAGE")` would always be `codex-rs/utils/cargo-bin`, which is not what we want.) Note we only consider the `BAZEL_PACKAGE` value when the `RUNFILES_DIR` environment variable is set at runtime, indicating that the test is being run by Bazel. In this case, we have to concatenate the runtime `RUNFILES_DIR` with the compile-time `BAZEL_PACKAGE` value to build the path to the resource. In testing this change, I discovered one funky edge case in `codex-rs/exec-server/tests/common/lib.rs` where we have to _normalize_ (but not canonicalize!) the result from `find_resource!` because the path contains a `common/..` component that does not exist on disk when the test is run under Bazel, so it must be semantically normalized using the [`path-absolutize`](https://crates.io/crates/path-absolutize) crate before it is passed to `dotslash fetch`. Because this new behavior may be non-obvious, this PR also updates `AGENTS.md` to make humans/Codex aware that this API is preferred.

zbarsky-openai · 2026-01-09T12:30:59Z

.github/workflows/Dockerfile.bazel

+RUN apt-get update && \
+    apt-get install -y --no-install-recommends \
+    build-essential curl git python3 ca-certificates \
+    pkg-config clang musl-tools libssl-dev && \


can we try to remove these?

pkg-config

clang

musl-tools

libssl-dev

(maybe, not sure) build-essential?

sorry to be a pain, but clang in particular is huge and i want to make sure we have no compilers in the base image so they're not used by accident :)

I mentally associate pkg-config with "python stuff," but chat says ends up being needed by some common Python packages that contain C extensions, so I agree that the builder host should not rely on those. Will try removing it.

in our case it's likely used by rust build scripts to find C libs on the host to link against. But we don't want that, we want the libs provided hermetically through bazel, as otherwise cross-compilation won't work

…s possible!

bolinfest

This is game-changing!

zbarsky-openai · 2026-01-09T18:27:53Z

🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢

bolinfest mentioned this pull request Jan 8, 2026

feat: introduce find_resource! macro that works with Cargo or Bazel #8879

Merged

zbarsky-openai force-pushed the zbarsky/bazel branch from 8058b29 to d79f369 Compare January 8, 2026 02:15

This was referenced Jan 8, 2026

fix: leverage codex_utils_cargo_bin() in codex-rs/core/tests/suite #8887

Merged

fix: leverage find_resource! macro in load_sse_fixture_with_id #8888

Merged

bolinfest force-pushed the zbarsky/bazel branch from 9c0be78 to 9e7f454 Compare January 8, 2026 08:44

bolinfest added a commit that referenced this pull request Jan 8, 2026

fix: leverage find_resource! macro in load_sse_fixture_with_id (#8888)

7520d8b

This helps prepare us for Bazel builds: #8875.

bolinfest added a commit that referenced this pull request Jan 8, 2026

fix: leverage codex_utils_cargo_bin() in codex-rs/core/tests/suite (#…

1e29774

…8887) This eliminates our dependency on the `escargot` crate and better prepares us for Bazel builds: #8875.

zbarsky-openai force-pushed the zbarsky/bazel branch from ff84352 to c0cb029 Compare January 8, 2026 15:04

zbarsky-openai commented Jan 8, 2026

View reviewed changes

codex-rs/core/src/shell_snapshot.rs Outdated Show resolved Hide resolved

zbarsky-openai commented Jan 8, 2026

View reviewed changes

.gitignore Outdated Show resolved Hide resolved

bolinfest reviewed Jan 8, 2026

View reviewed changes

bolinfest force-pushed the zbarsky/bazel branch from 938273f to f4d2a47 Compare January 8, 2026 17:43

This was referenced Jan 8, 2026

fix: correct login shell mismatch in the accept_elicitation_for_prompt_rule() test #8931

Merged

fix: increase timeout for tests that have been flaking with timeout issues #8932

Merged

bolinfest force-pushed the zbarsky/bazel branch from 086e308 to 72d3a0a Compare January 8, 2026 20:41

bolinfest changed the title ~~[please leave open, collaborating with mbolin] WIP: bazelification~~ feat: add support for building with Bazel Jan 8, 2026

bolinfest mentioned this pull request Jan 8, 2026

fix: increase timeout for wait_for_event() for Bazel #8946

Merged

bolinfest force-pushed the zbarsky/bazel branch from f71fc60 to 4428924 Compare January 8, 2026 23:41

zbarsky-openai commented Jan 9, 2026

View reviewed changes

zbarsky-openai force-pushed the zbarsky/bazel branch 2 times, most recently from f9dc9e8 to aeb3607 Compare January 9, 2026 04:06

bolinfest mentioned this pull request Jan 9, 2026

fix: add bazelisk and dotslash to Dockerfile for devcontainer #8959

Open

zbarsky-openai force-pushed the zbarsky/bazel branch from c4a26a7 to 7bf83c1 Compare January 9, 2026 12:28

zbarsky-openai commented Jan 9, 2026

View reviewed changes

bolinfest and others added 18 commits January 9, 2026 09:58

use smaller Dockerfile.bazel

6f6599e

ran pnpm run format:fix

da20a7d

use macos-15-xlarge instead of macos-14 for bazel.yml

a47530e

Add CI bazelrc

05abd7a

Cargo build script platform confusion

4a5a4fc

twiddle flags

9930533

fix build scripts?

b4e51e4

remove patch

48a5f2d

tweak platforms

f17f9c8

hax?

fed1ff5

Docs

6b17b6e

Straggling crate

bf1475c

fix: use slimmer .github/workflows/Dockerfile.bazel

ca1285c

typo fix

d271fc3

make .github/workflows/Dockerfile.bazel quite possibly as barebones a…

1cc541a

…s possible!

More docs

f44804e

just commands

9da75ae

add remote build just

775ea36

bolinfest force-pushed the zbarsky/bazel branch from 0a80ecf to 775ea36 Compare January 9, 2026 17:59

bolinfest self-requested a review January 9, 2026 18:17

bolinfest reviewed Jan 9, 2026

View reviewed changes

bolinfest approved these changes Jan 9, 2026

View reviewed changes

bolinfest mentioned this pull request Jan 9, 2026

feat: support local development using Buck2 #8504

Closed

zbarsky-openai force-pushed the zbarsky/bazel branch from 0e01c8c to 83debeb Compare January 9, 2026 18:53

add --platforms=//:rbe

458e07b

zbarsky-openai force-pushed the zbarsky/bazel branch from 83debeb to 458e07b Compare January 9, 2026 18:54

bolinfest merged commit 2a06d64 into main Jan 9, 2026
32 checks passed

bolinfest deleted the zbarsky/bazel branch January 9, 2026 19:09

github-actions bot locked and limited conversation to collaborators Jan 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: add support for building with Bazel #8875

feat: add support for building with Bazel #8875

zbarsky-openai commented Jan 8, 2026 •

edited by bolinfest

Loading

Uh oh!

github-actions bot commented Jan 8, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

bolinfest Jan 8, 2026

Uh oh!

Uh oh!

zbarsky-openai Jan 9, 2026

Uh oh!

Uh oh!

Uh oh!

zbarsky-openai Jan 9, 2026

Uh oh!

bolinfest Jan 9, 2026

Uh oh!

zbarsky-openai Jan 9, 2026

Uh oh!

bolinfest left a comment

Uh oh!

zbarsky-openai commented Jan 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		@@ -1,6 +1,8 @@
		#![allow(clippy::unwrap_used)]

		use codex_apply_patch::APPLY_PATCH_TOOL_INSTRUCTIONS;

feat: add support for building with Bazel #8875

feat: add support for building with Bazel #8875

Conversation

zbarsky-openai commented Jan 8, 2026 • edited by bolinfest Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CI

Uh oh!

github-actions bot commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bolinfest Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zbarsky-openai Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

zbarsky-openai Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

bolinfest Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

zbarsky-openai Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

bolinfest left a comment

Choose a reason for hiding this comment

Uh oh!

zbarsky-openai commented Jan 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

zbarsky-openai commented Jan 8, 2026 •

edited by bolinfest

Loading

github-actions bot commented Jan 8, 2026 •

edited

Loading