19 Commits

• bazel: use native rust test sharding (#18082)

  ## Why
  
  The large Rust test suites are slow and include some of our flakiest
  tests, so we want to run them with Bazel native sharding while keeping
  shard membership stable between runs.
  
  This is the simpler follow-up to the explicit-label experiment in
  #17998. Since #18397 upgraded Codex to `rules_rs` `0.0.58`, which
  includes the stable test-name hashing support from
  hermeticbuild/rules_rust#14, this PR only needs to wire Codex's Bazel
  macros into that support.
  
  Using native sharding preserves BuildBuddy's sharded-test UI and Bazel's
  per-shard test action caching. Using stable name hashing avoids
  reshuffling every test when one test is added or removed.
  
  ## What Changed
  
  `codex_rust_crate` now accepts `test_shard_counts` and applies the right
  Bazel/rules_rust attributes to generated unit and integration test
  rules. Matched tests are also marked `flaky = True`, giving them Bazel's
  default three attempts.
  
  This PR shards these labels 8 ways:
  
  ```text
  //codex-rs/core:core-all-test
  //codex-rs/core:core-unit-tests
  //codex-rs/app-server:app-server-all-test
  //codex-rs/app-server:app-server-unit-tests
  //codex-rs/tui:tui-unit-tests
  ```
  
  ## Verification
  
  `bazel query --output=build` over the selected public labels and their
  inner unit-test binaries confirmed the expected `shard_count = 8`,
  `flaky = True`, and `experimental_enable_sharding = True` attributes.
  
  Also verified that we see the shards as expected in BuildBuddy so they
  can be analyzed independently.
  
  Co-authored-by: Codex <noreply@openai.com>

  Michael Bolin · 2026-04-17 23:14:11 +00:00
  96d35dd640
• [docs] Revert extra changes from PR 17848 (#18003)

  ## Summary
  
  1. Revert https://github.com/openai/codex/pull/17848 so the Bazel and
  `BUILD` file changes leave `main`.
  2. Prepare for a narrower follow up that restores only `SECURITY.md`.
  
  ## Validation
  
  1. Reviewed the revert diff against `main`.
  2. Ran a clean diff check before push.

  evawong-oai · 2026-04-15 14:43:30 -07:00
  17d94bd1e3
• [docs] Add security boundaries reference in SECURITY.md (#17848)

  ## Summary
  1. Add a Security Boundaries section to `SECURITY.md`.
  2. Point readers to the Codex Agent approvals and security documentation
  for sandboxing, approvals, and network controls.
  
  ## Validation
  1. Reviewed the `SECURITY.md` diff in a clean worktree.
  2. No tests run. Docs only change.

  evawong-oai · 2026-04-15 20:12:46 +00:00
  0bb438bca6
• Wire realtime WebRTC native media into Bazel (#17145)

  - Builds codex-realtime-webrtc through the normal Bazel Rust macro so
  native macOS WebRTC sources are included.\n- Shares the macOS -ObjC link
  flag with Bazel targets that can link libwebrtc.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-08 15:15:55 -07:00
  19bd018300
• Codex/windows bazel rust test coverage no rs (#16528)

  # Why this PR exists
  
  This PR is trying to fix a coverage gap in the Windows Bazel Rust test
  lane.
  
  Before this change, the Windows `bazel test //...` job was nominally
  part of PR CI, but a non-trivial set of `//codex-rs/...` Rust test
  targets did not actually contribute test signal on Windows. In
  particular, targets such as `//codex-rs/core:core-unit-tests`,
  `//codex-rs/core:core-all-test`, and `//codex-rs/login:login-unit-tests`
  were incompatible during Bazel analysis on the Windows gnullvm platform,
  so they never reached test execution there. That is why the
  Cargo-powered Windows CI job could surface Windows-only failures that
  the Bazel-powered job did not report: Cargo was executing those tests,
  while Bazel was silently dropping them from the runnable target set.
  
  The main goal of this PR is to make the Windows Bazel test lane execute
  those Rust test targets instead of skipping them during analysis, while
  still preserving `windows-gnullvm` as the target configuration for the
  code under test. In other words: use an MSVC host/exec toolchain where
  Bazel helper binaries and build scripts need it, but continue compiling
  the actual crate targets with the Windows gnullvm cfgs that our current
  Bazel matrix is supposed to exercise.
  
  # Important scope note
  
  This branch intentionally removes the non-resource-loading `.rs` test
  and production-code changes from the earlier
  `codex/windows-bazel-rust-test-coverage` branch. The only Rust source
  changes kept here are runfiles/resource-loading fixes in TUI tests:
  
  - `codex-rs/tui/src/chatwidget/tests.rs`
  - `codex-rs/tui/tests/manager_dependency_regression.rs`
  
  That is deliberate. Since the corresponding tests already pass under
  Cargo, this PR is meant to test whether Bazel infrastructure/toolchain
  fixes alone are enough to get a healthy Windows Bazel test signal,
  without changing test behavior for Windows timing, shell output, or
  SQLite file-locking.
  
  # How this PR changes the Windows Bazel setup
  
  ## 1. Split Windows host/exec and target concerns in the Bazel test lane
  
  The core change is that the Windows Bazel test job now opts into an MSVC
  host platform for Bazel execution-time tools, but only for `bazel test`,
  not for the Bazel clippy build.
  
  Files:
  
  - `.github/workflows/bazel.yml`
  - `.github/scripts/run-bazel-ci.sh`
  - `MODULE.bazel`
  
  What changed:
  
  - `run-bazel-ci.sh` now accepts `--windows-msvc-host-platform`.
  - When that flag is present on Windows, the wrapper appends
  `--host_platform=//:local_windows_msvc` unless the caller already
  provided an explicit `--host_platform`.
  - `bazel.yml` passes that wrapper flag only for the Windows `bazel test
  //...` job.
  - The Bazel clippy job intentionally does **not** pass that flag, so
  clippy stays on the default Windows gnullvm host/exec path and continues
  linting against the target cfgs we care about.
  - `run-bazel-ci.sh` also now forwards `CODEX_JS_REPL_NODE_PATH` on
  Windows and normalizes the `node` executable path with `cygpath -w`, so
  tests that need Node resolve the runner's Node installation correctly
  under the Windows Bazel test environment.
  
  Why this helps:
  
  - The original incompatibility chain was mostly on the **exec/tool**
  side of the graph, not in the Rust test code itself. Moving host tools
  to MSVC lets Bazel resolve helper binaries and generators that were not
  viable on the gnullvm exec platform.
  - Keeping the target platform on gnullvm preserves cfg coverage for the
  crates under test, which is important because some Windows behavior
  differs between `msvc` and `gnullvm`.
  
  ## 2. Teach the repo's Bazel Rust macro about Windows link flags and
  integration-test knobs
  
  Files:
  
  - `defs.bzl`
  - `codex-rs/core/BUILD.bazel`
  - `codex-rs/otel/BUILD.bazel`
  - `codex-rs/tui/BUILD.bazel`
  
  What changed:
  
  - Replaced the old gnullvm-only linker flag block with
  `WINDOWS_RUSTC_LINK_FLAGS`, which now handles both Windows ABIs:
    - gnullvm gets `-C link-arg=-Wl,--stack,8388608`
  - MSVC gets `-C link-arg=/STACK:8388608`, `-C
  link-arg=/NODEFAULTLIB:libucrt.lib`, and `-C link-arg=ucrt.lib`
  - Threaded those Windows link flags into generated `rust_binary`,
  unit-test binaries, and integration-test binaries.
  - Extended `codex_rust_crate(...)` with:
    - `integration_test_args`
    - `integration_test_timeout`
  - Used those new knobs to:
  - mark `//codex-rs/core:core-all-test` as a long-running integration
  test
    - serialize `//codex-rs/otel:otel-all-test` with `--test-threads=1`
  - Added `src/**/*.rs` to `codex-rs/tui` test runfiles, because one
  regression test scans source files at runtime and Bazel does not expose
  source-tree directories unless they are declared as data.
  
  Why this helps:
  
  - Once host-side MSVC tools are available, we still need the generated
  Rust test binaries to link correctly on Windows. The MSVC-side
  stack/UCRT flags make those binaries behave more like their Cargo-built
  equivalents.
  - The integration-test macro knobs avoid hardcoding one-off test
  behavior in ad hoc BUILD rules and make the generated test targets more
  expressive where Bazel and Cargo have different runtime defaults.
  
  ## 3. Patch `rules_rs` / `rules_rust` so Windows MSVC exec-side Rust and
  build scripts are actually usable
  
  Files:
  
  - `MODULE.bazel`
  - `patches/rules_rs_windows_exec_linker.patch`
  - `patches/rules_rust_windows_bootstrap_process_wrapper_linker.patch`
  - `patches/rules_rust_windows_build_script_runner_paths.patch`
  - `patches/rules_rust_windows_exec_msvc_build_script_env.patch`
  - `patches/rules_rust_windows_msvc_direct_link_args.patch`
  - `patches/rules_rust_windows_process_wrapper_skip_temp_outputs.patch`
  - `patches/BUILD.bazel`
  
  What these patches do:
  
  - `rules_rs_windows_exec_linker.patch`
  - Adds a `rust-lld` filegroup for Windows Rust toolchain repos,
  symlinked to `lld-link.exe` from `PATH`.
    - Marks Windows toolchains as using a direct linker driver.
    - Supplies Windows stdlib link flags for both gnullvm and MSVC.
  - `rules_rust_windows_bootstrap_process_wrapper_linker.patch`
  - For Windows MSVC Rust targets, prefers the Rust toolchain linker over
  an inherited C++ linker path like `clang++`.
  - This specifically avoids the broken mixed-mode command line where
  rustc emits MSVC-style `/NOLOGO` / `/LIBPATH:` / `/OUT:` arguments but
  Bazel still invokes `clang++.exe`.
  - `rules_rust_windows_build_script_runner_paths.patch`
  - Normalizes forward-slash execroot-relative paths into Windows path
  separators before joining them on Windows.
  - Uses short Windows paths for `RUSTC`, `OUT_DIR`, and the build-script
  working directory to avoid path-length and quoting issues in third-party
  build scripts.
  - Exposes `RULES_RUST_BAZEL_BUILD_SCRIPT_RUNNER=1` to build scripts so
  crate-local patches can detect "this is running under Bazel's
  build-script runner".
  - Fixes the Windows runfiles cleanup filter so generated files with
  retained suffixes are actually retained.
  - `rules_rust_windows_exec_msvc_build_script_env.patch`
  - For exec-side Windows MSVC build scripts, stops force-injecting
  Bazel's `CC`, `CXX`, `LD`, `CFLAGS`, and `CXXFLAGS` when that would send
  GNU-flavored tool paths/flags into MSVC-oriented Cargo build scripts.
  - Rewrites or strips GNU-only `--sysroot`, MinGW include/library paths,
  stack-protector, and `_FORTIFY_SOURCE` flags on the MSVC exec path.
  - The practical effect is that build scripts can fall back to the Visual
  Studio toolchain environment already exported by CI instead of crashing
  inside Bazel's hermetic `clang.exe` setup.
  - `rules_rust_windows_msvc_direct_link_args.patch`
  - When using a direct linker on Windows, stops forwarding GNU driver
  flags such as `-L...` and `--sysroot=...` that `lld-link.exe` does not
  understand.
  - Passes non-`.lib` native artifacts as explicit `-Clink-arg=<path>`
  entries when needed.
  - Filters C++ runtime libraries to `.lib` artifacts on the Windows
  direct-driver path.
  - `rules_rust_windows_process_wrapper_skip_temp_outputs.patch`
  - Excludes transient `*.tmp*` and `*.rcgu.o` files from process-wrapper
  dependency search-path consolidation, so unstable compiler outputs do
  not get treated as real link search-path inputs.
  
  Why this helps:
  
  - The host-platform split alone was not enough. Once Bazel started
  analyzing/running previously incompatible Rust tests on Windows, the
  next failures were in toolchain plumbing:
  - MSVC-targeted Rust tests were being linked through `clang++` with
  MSVC-style arguments.
  - Cargo build scripts running under Bazel's Windows MSVC exec platform
  were handed Unix/GNU-flavored path and flag shapes.
  - Some generated paths were too long or had path-separator forms that
  third-party Windows build scripts did not tolerate.
  - These patches make that mixed Bazel/Cargo/Rust/MSVC path workable
  enough for the test lane to actually build and run the affected crates.
  
  ## 4. Patch third-party crate build scripts that were not robust under
  Bazel's Windows MSVC build-script path
  
  Files:
  
  - `MODULE.bazel`
  - `patches/aws-lc-sys_windows_msvc_prebuilt_nasm.patch`
  - `patches/ring_windows_msvc_include_dirs.patch`
  - `patches/zstd-sys_windows_msvc_include_dirs.patch`
  
  What changed:
  
  - `aws-lc-sys`
  - Detects Bazel's Windows MSVC build-script runner via
  `RULES_RUST_BAZEL_BUILD_SCRIPT_RUNNER` or a `bazel-out` manifest-dir
  path.
  - Uses `clang-cl` for Bazel Windows MSVC builds when no explicit
  `CC`/`CXX` is set.
  - Allows prebuilt NASM on the Bazel Windows MSVC path even when `nasm`
  is not available directly in the runner environment.
  - Avoids canonicalizing `CARGO_MANIFEST_DIR` in the Bazel Windows MSVC
  case, because that path may point into Bazel output/runfiles state where
  preserving the given path is more reliable than forcing a local
  filesystem canonicalization.
  - `ring`
  - Under the Bazel Windows MSVC build-script runner, copies the
  pregenerated source tree into `OUT_DIR` and uses that as the
  generated-source root.
  - Adds include paths needed by MSVC compilation for
  Fiat/curve25519/P-256 generated headers.
  - Rewrites a few relative includes in C sources so the added include
  directories are sufficient.
  - `zstd-sys`
  - Adds MSVC-only include directories for `compress`, `decompress`, and
  feature-gated dictionary/legacy/seekable sources.
  - Skips `-fvisibility=hidden` on MSVC targets, where that
  GCC/Clang-style flag is not the right mechanism.
  
  Why this helps:
  
  - After the `rules_rust` plumbing started running build scripts on the
  Windows MSVC exec path, some third-party crates still failed for
  crate-local reasons: wrong compiler choice, missing include directories,
  build-script assumptions about manifest paths, or Unix-only C compiler
  flags.
  - These crate patches address those crate-local assumptions so the
  larger toolchain change can actually reach first-party Rust test
  execution.
  
  ## 5. Keep the only `.rs` test changes to Bazel/Cargo runfiles parity
  
  Files:
  
  - `codex-rs/tui/src/chatwidget/tests.rs`
  - `codex-rs/tui/tests/manager_dependency_regression.rs`
  
  What changed:
  
  - Instead of asking `find_resource!` for a directory runfile like
  `src/chatwidget/snapshots` or `src`, these tests now resolve one known
  file runfile first and then walk to its parent directory.
  
  Why this helps:
  
  - Bazel runfiles are more reliable for explicitly declared files than
  for source-tree directories that happen to exist in a Cargo checkout.
  - This keeps the tests working under both Cargo and Bazel without
  changing their actual assertions.
  
  # What we tried before landing on this shape, and why those attempts did
  not work
  
  ## Attempt 1: Force `--host_platform=//:local_windows_msvc` for all
  Windows Bazel jobs
  
  This did make the previously incompatible test targets show up during
  analysis, but it also pushed the Bazel clippy job and some unrelated
  build actions onto the MSVC exec path.
  
  Why that was bad:
  
  - Windows clippy started running third-party Cargo build scripts with
  Bazel's MSVC exec settings and crashed in crates such as `tree-sitter`
  and `libsqlite3-sys`.
  - That was a regression in a job that was previously giving useful
  gnullvm-targeted lint signal.
  
  What this PR does instead:
  
  - The wrapper flag is opt-in, and `bazel.yml` uses it only for the
  Windows `bazel test` lane.
  - The clippy lane stays on the default Windows gnullvm host/exec
  configuration.
  
  ## Attempt 2: Broaden the `rules_rust` linker override to all Windows
  Rust actions
  
  This fixed the MSVC test-lane failure where normal `rust_test` targets
  were linked through `clang++` with MSVC-style arguments, but it broke
  the default gnullvm path.
  
  Why that was bad:
  
  -
  `@@rules_rs++rules_rust+rules_rust//util/process_wrapper:process_wrapper`
  on the gnullvm exec platform started linking with `lld-link.exe` and
  then failed to resolve MinGW-style libraries such as `-lkernel32`,
  `-luser32`, and `-lmingw32`.
  
  What this PR does instead:
  
  - The linker override is restricted to Windows MSVC targets only.
  - The gnullvm path keeps its original linker behavior, while MSVC uses
  the direct Windows linker.
  
  ## Attempt 3: Keep everything on pure Windows gnullvm and patch the V8 /
  Python incompatibility chain instead
  
  This would have preserved a single Windows ABI everywhere, but it is a
  much larger project than this PR.
  
  Why that was not the practical first step:
  
  - The original incompatibility chain ran through exec-side generators
  and helper tools, not only through crate code.
  - `third_party/v8` is already special-cased on Windows gnullvm because
  `rusty_v8` only publishes Windows prebuilts under MSVC names.
  - Fixing that path likely means deeper changes in
  V8/rules_python/rules_rust toolchain resolution and generator execution,
  not just one local CI flag.
  
  What this PR does instead:
  
  - Keep gnullvm for the target cfgs we want to exercise.
  - Move only the Windows test lane's host/exec platform to MSVC, then
  patch the build-script/linker boundary enough for that split
  configuration to work.
  
  ## Attempt 4: Validate compatibility with `bazel test --nobuild ...`
  
  This turned out to be a misleading local validation command.
  
  Why:
  
  - `bazel test --nobuild ...` can successfully analyze targets and then
  still exit 1 with "Couldn't start the build. Unable to run tests"
  because there are no runnable test actions after `--nobuild`.
  
  Better local check:
  
  ```powershell
  bazel build --nobuild --keep_going --host_platform=//:local_windows_msvc //codex-rs/login:login-unit-tests //codex-rs/core:core-unit-tests //codex-rs/core:core-all-test
  ```
  
  # Which patches probably deserve upstream follow-up
  
  My rough take is that the `rules_rs` / `rules_rust` patches are the
  highest-value upstream candidates, because they are fixing generic
  Windows host/exec + MSVC direct-linker behavior rather than
  Codex-specific test logic.
  
  Strong upstream candidates:
  
  - `patches/rules_rs_windows_exec_linker.patch`
  - `patches/rules_rust_windows_bootstrap_process_wrapper_linker.patch`
  - `patches/rules_rust_windows_build_script_runner_paths.patch`
  - `patches/rules_rust_windows_exec_msvc_build_script_env.patch`
  - `patches/rules_rust_windows_msvc_direct_link_args.patch`
  - `patches/rules_rust_windows_process_wrapper_skip_temp_outputs.patch`
  
  Why these seem upstreamable:
  
  - They address general-purpose problems in the Windows MSVC exec path:
    - missing direct-linker exposure for Rust toolchains
    - wrong linker selection when rustc emits MSVC-style args
  - Windows path normalization/short-path issues in the build-script
  runner
    - forwarding GNU-flavored CC/link flags into MSVC Cargo build scripts
    - unstable temp outputs polluting process-wrapper search-path state
  
  Potentially upstreamable crate patches, but likely with more care:
  
  - `patches/zstd-sys_windows_msvc_include_dirs.patch`
  - `patches/ring_windows_msvc_include_dirs.patch`
  - `patches/aws-lc-sys_windows_msvc_prebuilt_nasm.patch`
  
  Notes on those:
  
  - The `zstd-sys` and `ring` include-path fixes look fairly generic for
  MSVC/Bazel build-script environments and may be straightforward to
  propose upstream after we confirm CI stability.
  - The `aws-lc-sys` patch is useful, but it includes a Bazel-specific
  environment probe and CI-specific compiler fallback behavior. That
  probably needs a cleaner upstream-facing shape before sending it out, so
  upstream maintainers are not forced to adopt Codex's exact CI
  assumptions.
  
  Probably not worth upstreaming as-is:
  
  - The repo-local Starlark/test target changes in `defs.bzl`,
  `codex-rs/*/BUILD.bazel`, and `.github/scripts/run-bazel-ci.sh` are
  mostly Codex-specific policy and CI wiring, not generic rules changes.
  
  # Validation notes for reviewers
  
  On this branch, I ran the following local checks after dropping the
  non-resource-loading Rust edits:
  
  ```powershell
  cargo test -p codex-tui
  just --shell 'C:\Program Files\Git\bin\bash.exe' --shell-arg -lc -- fix -p codex-tui
  python .\tools\argument-comment-lint\run-prebuilt-linter.py -p codex-tui
  just --shell 'C:\Program Files\Git\bin\bash.exe' --shell-arg -lc fmt
  ```
  
  One local caveat:
  
  - `just argument-comment-lint` still fails on this Windows machine for
  an unrelated Bazel toolchain-resolution issue in
  `//codex-rs/exec:exec-all-test`, so I used the direct prebuilt linter
  for `codex-tui` as the local fallback.
  
  # Expected reviewer takeaway
  
  If this PR goes green, the important conclusion is that the Windows
  Bazel test coverage gap was primarily a Bazel host/exec toolchain
  problem, not a need to make the Rust tests themselves Windows-specific.
  That would be a strong signal that the deleted non-resource-loading Rust
  test edits from the earlier branch should stay out, and that future work
  should focus on upstreaming the generic `rules_rs` / `rules_rust`
  Windows fixes and reducing the crate-local patch surface.

  Michael Bolin · 2026-04-03 15:34:03 -07:00
  eaf12beacf
• build: migrate argument-comment-lint to a native Bazel aspect (#16106)

  ## Why
  
  `argument-comment-lint` had become a PR bottleneck because the repo-wide
  lane was still effectively running a `cargo dylint`-style flow across
  the workspace instead of reusing Bazel's Rust dependency graph. That
  kept the lint enforced, but it threw away the main benefit of moving
  this job under Bazel in the first place: metadata reuse and cacheable
  per-target analysis in the same shape as Clippy.
  
  This change moves the repo-wide lint onto a native Bazel Rust aspect so
  Linux and macOS can lint `codex-rs` without rebuilding the world
  crate-by-crate through the wrapper path.
  
  ## What Changed
  
  - add a nightly Rust toolchain with `rustc-dev` for Bazel and a
  dedicated crate-universe repo for `tools/argument-comment-lint`
  - add `tools/argument-comment-lint/driver.rs` and
  `tools/argument-comment-lint/lint_aspect.bzl` so Bazel can run the lint
  as a custom `rustc_driver`
  - switch repo-wide `just argument-comment-lint` and the Linux/macOS
  `rust-ci` lanes to `bazel build --config=argument-comment-lint
  //codex-rs/...`
  - keep the Python/DotSlash wrappers as the package-scoped fallback path
  and as the current Windows CI path
  - gate the Dylint entrypoint behind a `bazel_native` feature so the
  Bazel-native library avoids the `dylint_*` packaging stack
  - update the aspect runtime environment so the driver can locate
  `rustc_driver` correctly under remote execution
  - keep the dedicated `tools/argument-comment-lint` package tests and
  wrapper unit tests in CI so the source and packaged entrypoints remain
  covered
  
  ## Verification
  
  - `python3 -m unittest discover -s tools/argument-comment-lint -p
  'test_*.py'`
  - `cargo test` in `tools/argument-comment-lint`
  - `bazel build
  //tools/argument-comment-lint:argument-comment-lint-driver
  --@rules_rust//rust/toolchain/channel=nightly`
  - `bazel build --config=argument-comment-lint
  //codex-rs/utils/path-utils:all`
  - `bazel build --config=argument-comment-lint
  //codex-rs/rollout:rollout`
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16106).
  * #16120
  * __->__ #16106

  Michael Bolin · 2026-03-28 12:41:56 -07:00
  fce0f76d57
• bazel: add Windows gnullvm stack flags to unit test binaries (#16074)

  ## Summary
  
  Add the Windows gnullvm stack-reserve flags to the `*-unit-tests-bin`
  path in `codex_rust_crate()`.
  
  ## Why
  
  This is the narrow code fix behind the earlier review comment on
  [#16067](https://github.com/openai/codex/pull/16067). That comment was
  stale relative to the workflow-only PR it landed on, but it pointed at a
  real gap in `defs.bzl`.
  
  Today, `codex_rust_crate()` already appends
  `WINDOWS_GNULLVM_RUSTC_STACK_FLAGS` for:
  
  - `rust_binary()` targets
  - integration-test `rust_test()` targets
  
  But the unit-test binary path still omitted those flags. That meant the
  generated `*-unit-tests-bin` executables were not built the same way as
  the rest of the Windows gnullvm executables in the macro.
  
  ## What Changed
  
  - Added `WINDOWS_GNULLVM_RUSTC_STACK_FLAGS` to the `unit_test_binary`
  `rust_test()` rule in `defs.bzl`
  - Added a short comment explaining why unit-test binaries need the same
  stack-reserve treatment as binaries and integration tests on Windows
  gnullvm
  
  ## Testing
  
  - `bazel query '//codex-rs/core:*'`
  - `bazel query '//codex-rs/shell-command:*'`
  
  Those queries load packages that exercise `codex_rust_crate()`,
  including `*-unit-tests-bin` targets. The actual runtime effect is
  Windows-specific, so the real end-to-end confirmation still comes from
  Windows CI.

  Michael Bolin · 2026-03-27 22:11:49 -07:00
  e39ddc61b1
• bazel: enable the full Windows gnullvm CI path (#15952)

  ## Why
  
  This PR is the current, consolidated follow-up to the earlier Windows
  Bazel attempt in #11229. The goal is no longer just to get a tiny
  Windows smoke job limping along: it is to make the ordinary Bazel CI
  path usable on `windows-latest` for `x86_64-pc-windows-gnullvm`, with
  the same broad `//...` test shape that macOS and Linux already use.
  
  The earlier smoke-list version of this work was useful as a foothold,
  but it was not a good long-term landing point. Windows Bazel kept
  surfacing real issues outside that allowlist:
  
  - GitHub's Windows runner exposed runfiles-manifest bugs such as
  `FINDSTR: Cannot open D:MANIFEST`, which broke Bazel test launchers even
  when the manifest file existed.
  - `rules_rs`, `rules_rust`, LLVM extraction, and Abseil still needed
  `windows-gnullvm`-specific fixes for our hermetic toolchain.
  - the V8 path needed more work than just turning the Windows matrix
  entry back on: `rusty_v8` does not ship Windows GNU artifacts in the
  same shape we need, and Bazel's in-tree V8 build needed a set of Windows
  GNU portability fixes.
  
  Windows performance pressure also pushed this toward a full solution
  instead of a permanent smoke suite. During this investigation we hit
  targets such as `//codex-rs/shell-command:shell-command-unit-tests` that
  were much more expensive on Windows because they repeatedly spawn real
  PowerShell parsers (see #16057 for one concrete example of that
  pressure). That made it much more valuable to get the real Windows Bazel
  path working than to keep iterating on a narrowly curated subset.
  
  The net result is that this PR now aims for the same CI contract on
  Windows that we already expect elsewhere: keep standalone
  `//third_party/v8:all` out of the ordinary Bazel lane, but allow V8
  consumers under `//codex-rs/...` to build and test transitively through
  `//...`.
  
  ## What Changed
  
  ### CI and workflow wiring
  
  - re-enable the `windows-latest` / `x86_64-pc-windows-gnullvm` Bazel
  matrix entry in `.github/workflows/bazel.yml`
  - move the Windows Bazel output root to `D:\b` and enable `git config
  --global core.longpaths true` in
  `.github/actions/setup-bazel-ci/action.yml`
  - keep the ordinary Bazel target set on Windows aligned with macOS and
  Linux by running `//...` while excluding only standalone
  `//third_party/v8:all` targets from the normal lane
  
  ### Toolchain and module support for `windows-gnullvm`
  
  - patch `rules_rs` so `windows-gnullvm` is modeled as a distinct Windows
  exec/toolchain platform instead of collapsing into the generic Windows
  shape
  - patch `rules_rust` build-script environment handling so llvm-mingw
  build-script probes do not inherit unsupported `-fstack-protector*`
  flags
  - patch the LLVM module archive so it extracts cleanly on Windows and
  provides the MinGW libraries this toolchain needs
  - patch Abseil so its thread-local identity path matches the hermetic
  `windows-gnullvm` toolchain instead of taking an incompatible MinGW
  pthread path
  - keep both MSVC and GNU Windows targets in the generated Cargo metadata
  because the current V8 release-asset story still uses MSVC-shaped names
  in some places while the Bazel build targets the GNU ABI
  
  ### Windows test-launch and binary-behavior fixes
  
  - update `workspace_root_test_launcher.bat.tpl` to read the runfiles
  manifest directly instead of shelling out to `findstr`, which was the
  source of the `D:MANIFEST` failures on the GitHub Windows runner
  - thread a larger Windows GNU stack reserve through `defs.bzl` so
  Bazel-built binaries that pull in V8 behave correctly both under normal
  builds and under `bazel test`
  - remove the no-longer-needed Windows bootstrap sh-toolchain override
  from `.bazelrc`
  
  ### V8 / `rusty_v8` Windows GNU support
  
  - export and apply the new Windows GNU patch set from
  `patches/BUILD.bazel` / `MODULE.bazel`
  - patch the V8 module/rules/source layers so the in-tree V8 build can
  produce Windows GNU archives under Bazel
  - teach `third_party/v8/BUILD.bazel` to build Windows GNU static
  archives in-tree instead of aliasing them to the MSVC prebuilts
  - reuse the Linux release binding for the experimental Windows GNU path
  where `rusty_v8` does not currently publish a Windows GNU binding
  artifact
  
  ## Testing
  
  - the primary end-to-end validation for this work is the `Bazel`
  workflow plus `v8-canary`, since the hard parts are Windows-specific and
  depend on real GitHub runner behavior
  - before consolidation back onto this PR, the same net change passed the
  full Bazel matrix in [run
  23675590471](https://github.com/openai/codex/actions/runs/23675590471)
  and passed `v8-canary` in [run
  23675590453](https://github.com/openai/codex/actions/runs/23675590453)
  - those successful runs included the `windows-latest` /
  `x86_64-pc-windows-gnullvm` Bazel job with the ordinary `//...` path,
  not the earlier Windows smoke allowlist
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/15952).
  * #16067
  * __->__ #15952

  Michael Bolin · 2026-03-27 20:37:03 -07:00
  343d1af3da
• fix(ci): restore guardian coverage and bazel unit tests (#13912)

  ## Summary
  - restore the guardian review request snapshot test and its tracked
  snapshot after it was dropped from `main`
  - make Bazel Rust unit-test wrappers resolve runfiles correctly on
  manifest-only platforms like macOS and point Insta at the real workspace
  root
  - harden the shell-escalation socket-closure assertion so the musl Bazel
  test no longer depends on fd reuse behavior
  
  ## Verification
  - cargo test -p codex-core
  guardian_review_request_layout_matches_model_visible_request_snapshot
  - cargo test -p codex-shell-escalation
  - bazel test //codex-rs/exec:exec-unit-tests
  //codex-rs/shell-escalation:shell-escalation-unit-tests
  
  Supersedes #13894.
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>
  Co-authored-by: viyatb-oai <viyatb@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-08 12:05:19 -07:00
  7ba1fccfc1
• [bazel] Bump rules_rs and llvm (#13366)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  zbarsky-openai · 2026-03-04 01:59:32 +00:00
  2d8c1575b8
• [bazel] Fix proc_macro_dep libs (#12274)

  If a first-party proc_macro crate has tests/binaries that would get
  autogenerated by the macro, it was being handled incorrectly. Found by
  an external OS contributor!

  zbarsky-openai · 2026-02-19 13:38:37 -08:00
  2668789560
• bazel: fix snapshot parity for tests/*.rs rust_test targets (#11893)

  ## Summary
  - make `rust_test` targets generated from `tests/*.rs` use Cargo-style
  crate names (file stem) so snapshot names match Cargo (`all__...`
  instead of Bazel-derived names)
  - split lib vs `tests/*.rs` test env wiring in `codex_rust_crate` to
  keep existing lib snapshot behavior while applying Bazel
  runfiles-compatible workspace root for `tests/*.rs`
  - compute the `tests/*.rs` snapshot workspace root from package depth so
  `insta` resolves committed snapshots under Bazel `--noenable_runfiles`
  
  ## Validation
  - `bazelisk test //codex-rs/core:core-all-test
  --test_arg=suite::compact:: --cache_test_results=no`
  - `bazelisk test //codex-rs/core:core-all-test
  --test_arg=suite::compact_remote:: --cache_test_results=no`

  Anton Panasenko · 2026-02-16 07:11:59 +00:00
  1d95656149
• build(linux-sandbox): always compile vendored bubblewrap on Linux; remove CODEX_BWRAP_ENABLE_FFI (#11498)

  ## 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>

  viyatb-oai · 2026-02-11 21:30:41 -08:00
  923f931121
• [bazel] Upgrade some rulesets in preparation for enabling windows, part 2 (#11197)

  https://github.com/openai/codex/pull/11109 had automerge set, so I
  didn't get to address feedback before merging, oops!

  zbarsky-openai · 2026-02-09 20:08:10 +00:00
  86183847fd
• [bazel] Upgrade some rulesets in preparation for enabling windows (#11109)
  zbarsky-openai · 2026-02-08 13:40:32 -08:00
  44a1355133
• feat: experimental flags (#10231)

  ## Problem being solved
  - We need a single, reliable way to mark app-server API surface as
  experimental so that:
    1. the runtime can reject experimental usage unless the client opts in
  2. generated TS/JSON schemas can exclude experimental methods/fields for
  stable clients.
  
  Right now that’s easy to drift or miss when done ad-hoc.
  
  ## How to declare experimental methods and fields
  - **Experimental method**: add `#[experimental("method/name")]` to the
  `ClientRequest` variant in `client_request_definitions!`.
  - **Experimental field**: on the params struct, derive `ExperimentalApi`
  and annotate the field with `#[experimental("method/name.field")]` + set
  `inspect_params: true` for the method variant so
  `ClientRequest::experimental_reason()` inspects params for experimental
  fields.
  
  ## How the macro solves it
  - The new derive macro lives in
  `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
  `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
  attributes.
  - **Structs**:
  - Generates `ExperimentalApi::experimental_reason(&self)` that checks
  only annotated fields.
    - The “presence” check is type-aware:
      - `Option<T>`: `is_some_and(...)` recursively checks inner.
      - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
      - `bool`: must be `true`.
      - Other types: considered present (returns `true`).
  - Registers each experimental field in an `inventory` with `(type_name,
  serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
  that type. Field names are converted from `snake_case` to `camelCase`
  for schema/TS filtering.
  - **Enums**:
  - Generates an exhaustive `match` returning `Some(reason)` for annotated
  variants and `None` otherwise (no wildcard arm).
  - **Wiring**:
  - Runtime gating uses `ExperimentalApi::experimental_reason()` in
  `codex-rs/app-server/src/message_processor.rs` to reject requests unless
  `InitializeParams.capabilities.experimental_api == true`.
  - Schema/TS export filters use the inventory list and
  `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
  strip experimental methods/fields when `experimental_api` is false.

  jif-oai · 2026-02-02 11:06:50 +00:00
  3cc9122ee2
• [bazel] Improve runfiles handling (#10098)

  we can't use runfiles directory on Windows due to path lengths, so swap
  to manifest strategy. Parsing the manifest is a bit complex and the
  format is changing in Bazel upstream, so pull in the official Rust
  library (via a small hack to make it importable...) and cleanup all the
  associated logic to work cleanly in both bazel and cargo without extra
  confusion

  zbarsky-openai · 2026-01-29 00:15:44 +00:00
  8497163363
• Remove stale TODO comment from defs.bzl (#9787)

  ### Motivation
  - Remove an outdated comment in `defs.bzl` referencing
  `cargo_build_script` that is no longer relevant.
  
  ### Description
  - Delete the stale `# TODO(zbarsky): cargo_build_script support?` line
  so the logic flows directly from `binaries` to `lib_srcs` in `defs.bzl`.
  
  ### Testing
  - Ran `git diff --check` which produced no errors.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6973d9ac757c8331be475a8fb0f90a88)

  jcoens-openai · 2026-01-23 20:30:01 +00:00
  e04851816d
• feat: add support for building with Bazel (#8875)

  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>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9