mirror of
https://github.com/openai/codex.git
synced 2026-05-13 15:52:40 +00:00
fa5d45227fbc56b8fdddfcb2bbdcd9666ea48d79
328 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Michael Bolin
|
30de54da36 |
bazel: run sharded rust integration tests (#21057)
## Why Bazel CI was not actually exercising some sharded Rust integration-test targets on macOS. The `rules_rust` sharding wrapper expects a symlink runfiles tree, but this repo runs Bazel with `--noenable_runfiles`. In that configuration the wrapper could fail to find the generated test binary, produce an empty test list, and exit successfully. That made targets such as `//codex-rs/core:core-all-test` look green even when Cargo CI could still catch failures in the same Rust tests. The coverage gap appears to have been introduced by [#18082](https://github.com/openai/codex/pull/18082), which enabled rules_rust native sharding on `//codex-rs/core:core-all-test` and the other large Rust test labels. The manifest-runfiles setup itself predates that change in [#10098](https://github.com/openai/codex/pull/10098), but #18082 is where the affected integration tests started running through the incompatible rules_rust sharding wrapper. [#18913](https://github.com/openai/codex/pull/18913) fixed the same class of issue for wrapped unit-test shards, but integration-test shards were still going through the rules_rust wrapper until this PR. We still do not have the V8/code-mode pieces stable under the Bazel CI cross-compile setup, so this keeps those tests out of Bazel while restoring coverage for the rest of the sharded Rust integration suites. Cargo CI remains responsible for V8/code-mode coverage for now. This change did uncover a real failing core test on `main`: `approved_folder_write_request_permissions_unblocks_later_apply_patch`. That fix is split into [#21060](https://github.com/openai/codex/pull/21060), which enables the `apply_patch` tool in the test, teaches the aggregate core test binary to dispatch the sandboxed filesystem helper, canonicalizes the macOS temp patch target, and isolates the core test harness from managed local/enterprise config. Keeping that fix separate lets this PR stay focused on restoring Bazel coverage while documenting the first failure it exposed. ## What changed - Build sharded Rust integration tests as manual `*-bin` binaries and run them through the existing manifest-aware `workspace_root_test` launcher. - Keep Bazel sharding on the launcher target so Rust test cases are still distributed by stable test-name hashing. - Configure Bazel CI to skip Rust tests whose names contain `suite::code_mode::`. - Exclude the standalone `codex-rs/code-mode` and `codex-rs/v8-poc` unit-test targets from `bazel.yml`. ## Verification - `bazel query --output=build //codex-rs/core:core-all-test` now shows `workspace_root_test` wrapping `//codex-rs/core:core-all-test-bin`. - `bazel test --test_output=all --nocache_test_results --test_sharding_strategy=disabled //codex-rs/core:core-all-test --test_filter=suite::request_permissions_tool::approved_folder_write_request_permissions_unblocks_later_apply_patch` runs the actual Rust test body and passes. - `bazel test --test_output=errors --nocache_test_results --test_env=CODEX_BAZEL_TEST_SKIP_FILTERS=suite::code_mode:: //codex-rs/core:core-all-test` runs the sharded target with code-mode skipped and passes overall locally, with one flaky attempt retried by the existing `flaky = True` setting. |
||
|
Eric Traut
|
39555036a3 |
[codex] Add issue labeler area labels (#20893)
## Why The automated issue labeler needs more precise area labels for newly opened GitHub issues so triage can distinguish new Codex app and agent feature surfaces without falling back to broad labels. ## What Changed - Added labeler prompt entries for `computer-use`, `browser`, `memory`, `imagen`, `remote`, `performance`, `automations`, and `pets` in `.github/workflows/issue-labeler.yml`. - Updated the agent-area guidance so `memory` is used for agentic memory storage/retrieval and `performance` is used for slow behavior, high memory utilization, and leaks. - Expanded the fallback `agent` guidance so Codex prefers the new specific labels when applicable. ## Verification - Parsed `.github/workflows/issue-labeler.yml` with `yq e '.'`. - Ran `git diff --check` for the workflow change. |
||
|
Michael Bolin
|
cd2760fc08 |
ci: cross-compile Windows Bazel clippy (#20701)
## Why #20585 moved the Windows Bazel test job to the cross-compile path, but the Windows Bazel clippy and verify-release-build jobs were still using the native Windows/MSVC-host fallback. Those two jobs became the slowest Windows PR legs, even though both are build-only signal and do not need to execute the resulting binaries. ## What Changed - Switches the Windows Bazel clippy job from `--windows-msvc-host-platform` to `--windows-cross-compile`, so clippy build actions use Linux RBE while still targeting `x86_64-pc-windows-gnullvm`. - Switches the Windows Bazel verify-release-build job to `--windows-cross-compile` as well. This job only compiles `cfg(not(debug_assertions))` Rust code under `fastbuild`, so it does not need a native Windows build host. - Keeps the old `--skip_incompatible_explicit_targets` behavior only for fork/community PRs without `BUILDBUDDY_API_KEY`, where `run-bazel-ci.sh` falls back to the local Windows MSVC-host shape. - Adds `--windows-cross-compile` support to `.github/scripts/run-bazel-query-ci.sh`, so target-discovery queries select the same `ci-windows-cross` config as the subsequent build. - Threads that option through `scripts/list-bazel-clippy-targets.sh` so the Windows clippy job discovers targets under the same platform shape as the subsequent clippy build. ## Verification Local checks: ```shell bash -n .github/scripts/run-bazel-query-ci.sh bash -n scripts/list-bazel-clippy-targets.sh ruby -e 'require "yaml"; YAML.load_file(".github/workflows/bazel.yml"); puts "ok"' RUNNER_OS=Linux ./scripts/list-bazel-clippy-targets.sh | grep -c -- '-windows-cross-bin$' RUNNER_OS=Windows ./scripts/list-bazel-clippy-targets.sh --windows-cross-compile | grep -c -- '-windows-cross-bin$' ``` The Linux target-list check reported `0` Windows-cross internal test binaries, while the Windows cross target-list check reported `47`, preserving the test-code clippy coverage shape from the existing Windows job. |
||
|
Michael Bolin
|
466798aa83 |
ci: cross-compile Windows Bazel tests (#20585)
## Status This is the Bazel PR-CI cross-compilation follow-up to #20485. It is intentionally split from the Cargo/cargo-xwin release-build PoC so #20485 can stay as the historical release-build exploration. The unrelated async-utils test cleanup has been moved to #20686, so this PR is focused on the Windows Bazel CI path. The intended tradeoff is now explicit in `.github/workflows/bazel.yml`: pull requests get the fast Windows cross-compiled Bazel test leg, while post-merge pushes to `main` run both that fast cross leg and a fully native Windows Bazel test leg. The native main-only job keeps full V8/code-mode coverage and gets a 40-minute timeout because it is less latency-sensitive than PR CI. All other Bazel jobs remain at 30 minutes. ## Why Windows Bazel PR CI currently does the expensive part of the build on Windows. A native Windows Bazel test job on `main` completed in about 28m12s, leaving very little headroom under the 30-minute job timeout and making Windows the slowest PR signal. #20485 showed that Windows cross-compilation can be materially faster for Cargo release builds, but PR CI needs Bazel because Bazel owns our test sharding, flaky-test retries, and integration-test layout. This PR applies the same high-level shape we already use for macOS Bazel CI: compile with remote Linux execution, then run platform-specific tests on the platform runner. The compromise is deliberately signal-aware: code-mode/V8 changes are rare enough that PR CI can accept losing the direct V8/code-mode smoke-test signal temporarily, while `main` still runs the native Windows job post-merge to catch that class of regression. A follow-up PR should investigate making the cross-built Windows gnullvm V8 archive pass the direct V8/code-mode tests so this tradeoff can eventually go away. ## What Changed - Adds a `ci-windows-cross` Bazel config that targets `x86_64-pc-windows-gnullvm`, uses Linux RBE for build actions, and keeps `TestRunner` actions local on the Windows runner. - Adds explicit Windows platform definitions for `windows_x86_64_gnullvm`, `windows_x86_64_msvc`, and a bridge toolchain that lets gnullvm test targets execute under the Windows MSVC host platform. - Updates the Windows Bazel PR test leg to opt into the cross-compile path via `--windows-cross-compile` and `--remote-download-toplevel`. - Adds a `test-windows-native-main` job that runs only for `push` events on `refs/heads/main`, uses the native Windows Bazel path, includes V8/code-mode smoke tests, and has `timeout-minutes: 40`. - Keeps fork/community PRs without `BUILDBUDDY_API_KEY` on the previous local Windows MSVC-host fallback, including `--host_platform=//:local_windows_msvc` and `--jobs=8`. - Preserves the existing integration-test shape on non-gnullvm platforms, while generating Windows-cross wrapper targets only for `windows_gnullvm`. - Resolves `CARGO_BIN_EXE_*` values from runfiles at test runtime, avoiding hard-coded Cargo paths and duplicate test runfiles. - Extends the V8 Bazel patches enough for the `x86_64-pc-windows-gnullvm` target and Linux remote execution path. - Makes the Windows sandbox test cwd derive from `INSTA_WORKSPACE_ROOT` at runtime when Bazel provides it, because cross-compiled binaries may contain Linux compile-time paths. - Keeps the direct V8/code-mode unit smoke tests out of the Windows cross PR path for now while native Windows CI continues to cover them post-merge. ## Command Shape The fast Windows PR test leg invokes the normal Bazel CI wrapper like this: ```shell ./.github/scripts/run-bazel-ci.sh \ --print-failed-action-summary \ --print-failed-test-logs \ --windows-cross-compile \ --remote-download-toplevel \ -- \ test \ --test_tag_filters=-argument-comment-lint \ --test_verbose_timeout_warnings \ --build_metadata=COMMIT_SHA=${GITHUB_SHA} \ -- \ //... \ -//third_party/v8:all \ -//codex-rs/code-mode:code-mode-unit-tests \ -//codex-rs/v8-poc:v8-poc-unit-tests ``` With the BuildBuddy secret available on Windows, the wrapper selects `--config=ci-windows-cross` and appends the important Windows-cross overrides after rc expansion: ```shell --host_platform=//:rbe --shell_executable=/bin/bash --action_env=PATH=/usr/bin:/bin --host_action_env=PATH=/usr/bin:/bin --test_env=PATH=${CODEX_BAZEL_WINDOWS_PATH} ``` The native post-merge Windows job intentionally omits `--windows-cross-compile` and does not exclude the V8/code-mode unit targets: ```shell ./.github/scripts/run-bazel-ci.sh \ --print-failed-action-summary \ --print-failed-test-logs \ -- \ test \ --test_tag_filters=-argument-comment-lint \ --test_verbose_timeout_warnings \ --build_metadata=COMMIT_SHA=${GITHUB_SHA} \ --build_metadata=TAG_windows_native_main=true \ -- \ //... \ -//third_party/v8:all ``` ## Research Notes The existing macOS Bazel CI config already uses the model we want here: build actions run remotely with `--strategy=remote`, but `TestRunner` actions execute on the macOS runner. This PR mirrors that pattern for Windows with `--strategy=TestRunner=local`. The important Bazel detail is that `rules_rs` is already targeting `x86_64-pc-windows-gnullvm` for Windows Bazel PR tests. This PR changes where the build actions execute; it does not switch the Bazel PR test target to Cargo, `cargo-nextest`, or the MSVC release target. Cargo release builds differ from this Bazel path for V8: the normal Windows Cargo release target is MSVC, and `rusty_v8` publishes prebuilt Windows MSVC `.lib.gz` archives. The Bazel PR path targets `windows-gnullvm`; `rusty_v8` does not publish a prebuilt Windows GNU/gnullvm archive, so this PR builds that archive in-tree. That Linux-RBE-built gnullvm archive currently crashes in direct V8/code-mode smoke tests, which is why the workflow keeps native Windows coverage on `main`. The less obvious Bazel detail is test wrapper selection. Bazel chooses the Windows test wrapper (`tw.exe`) from the test action execution platform, not merely from the Rust target triple. The outer `workspace_root_test` therefore declares the default test toolchain and uses the bridge toolchain above so the test action executes on Windows while its inner Rust binary is built for gnullvm. The V8 investigation exposed a Windows-client gotcha: even when an action execution platform is Linux RBE, Bazel can still derive the genrule shell path from the Windows client. That produced remote commands trying to run `C:\Program Files\Git\usr\bin\bash.exe` on Linux workers. The wrapper now passes `--shell_executable=/bin/bash` with `--host_platform=//:rbe` for the Windows cross path. The same Windows-client/Linux-RBE boundary also affected `third_party/v8:binding_cc`: a multiline genrule command can carry CRLF line endings into Linux remote bash, which failed as `$'\r'`. That genrule now keeps the `sed` command on one physical shell line while using an explicit Starlark join so the shell arguments stay readable. ## Verification Local checks included: ```shell bash -n .github/scripts/run-bazel-ci.sh bash -n workspace_root_test_launcher.sh.tpl ruby -e "require %q{yaml}; YAML.load_file(%q{.github/workflows/bazel.yml}); puts %q{ok}" RUNNER_OS=Linux ./scripts/list-bazel-clippy-targets.sh RUNNER_OS=Windows ./scripts/list-bazel-clippy-targets.sh RUNNER_OS=Linux ./tools/argument-comment-lint/list-bazel-targets.sh RUNNER_OS=Windows ./tools/argument-comment-lint/list-bazel-targets.sh ``` The Linux clippy and argument-comment target lists contain zero `*-windows-cross-bin` labels, while the Windows lists still include 47 Windows-cross internal test binaries. CI evidence: - Baseline native Windows Bazel test on `main`: success in about 28m12s, https://github.com/openai/codex/actions/runs/25206257208/job/73907325959 - Green Windows-cross Bazel run on the split PR before adding the main-only native leg: Windows test 9m16s, Windows release verify 5m10s, Windows clippy 4m43s, https://github.com/openai/codex/actions/runs/25231890068 - The latest SHA adds the explicit PR-vs-main tradeoff in `bazel.yml`; CI is rerunning on that focused diff. ## Follow-Up A subsequent PR should investigate making a cross-built Windows binary work with V8/code-mode enabled. Likely options are either making the Linux-RBE-built `windows-gnullvm` V8 archive correct at runtime, or evaluating whether a Bazel MSVC target/toolchain can reuse the same prebuilt MSVC `rusty_v8` archive shape that Cargo release builds already use. |
||
|
jif-oai
|
5744b85b9a |
fix: cargo deny (#20627)
Fix cargo deny by ack the `RUSTSEC` while a fix land
```
RUSTSEC-2026-0118
NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
RUSTSEC-2026-0119
CPU exhaustion during message encoding due to O(n²) name compression
Dependency path:
hickory-proto 0.25.2
└── hickory-resolver 0.25.2
└── rama-dns 0.3.0-alpha.4
└── rama-tcp 0.3.0-alpha.4
└── codex-network-proxy
```
Also upgrade some workers version to prevent this:
```
warning[license-not-encountered]: license was not encountered
┌─ ./codex-rs/deny.toml:131:6
│
131 │ "OpenSSL",
│ ━━━━━━━ unmatched license allowance
warning[duplicate]: found 2 duplicate entries for crate 'base64'
┌─ /github/workspace/codex-rs/Cargo.lock:79:1
│
79 │ ╭ base64 0.21.7 registry+https://github.com/rust-lang/crates.io-index
80 │ │ base64 0.22.1 registry+https://github.com/rust-lang/crates.io-index
│ ╰───────────────────────────────────────────────────────────────────┘ lock entries
```
|
||
|
Michael Bolin
|
ae863e72a2 |
ci: increase Windows release workflow timeouts (#20343)
## Why #20271 increased the `90`-minute timeout in `rust-release.yml`, but it did not update the reusable Windows workflow in `rust-release-windows.yml`. As a result, the Windows release compile jobs were still capped at `60` minutes and the `windows-x64` primary build could continue timing out. We are keeping the existing `90`-minute timeout in `rust-release.yml`. That increase was still directionally correct because the top-level release build benefits from extra headroom; the mistake was assuming it also covered the reusable Windows jobs. ## What Changed - increase the reusable Windows release workflow timeouts in `rust-release-windows.yml` from `60` minutes to `90` minutes - update the comment in `rust-release.yml` so it no longer implies that the top-level timeout covers the Windows reusable jobs |
||
|
Michael Bolin
|
6eab7519b4 |
chore: increase release build timeout from 60 min to 90 (#20271)
Build times are creeping up, so increase the timeout as a precaution. |
||
|
Michael Bolin
|
cafe717dca |
ci: migrate Bazel setup away from archived setup-bazelisk (#19851)
## Why All Bazel CI jobs are currently blocked in the `setup-bazelisk` step while trying to download Bazelisk. [`bazelbuild/setup-bazelisk`](https://github.com/bazelbuild/setup-bazelisk) is archived, and its README now recommends migrating to [`bazel-contrib/setup-bazel`](https://github.com/bazel-contrib/setup-bazel), so leaving our workflows on the archived action leaves CI exposed to exactly this sort of outage. Because `v8-canary` now consumes the shared local `setup-bazel-ci` action, that workflow also needs to trigger when the action changes. Without that follow-up, Bazel bootstrap regressions specific to the V8 canary path could be skipped by the workflow path filters. ## What Changed - Switched `.github/actions/setup-bazel-ci/action.yml` from `bazelbuild/setup-bazelisk` to `bazel-contrib/setup-bazel`, pinned to `0.19.0`. - Left `bazelisk-version` unset so GitHub-hosted runners can use their preinstalled Bazelisk instead of downloading `1.x` at job start. - Updated `.github/workflows/rusty-v8-release.yml` and `.github/workflows/v8-canary.yml` to use the shared `setup-bazel-ci` action instead of referencing `setup-bazelisk` directly. - Added `.github/actions/setup-bazel-ci/**` to the `pull_request` and `push` path filters in `.github/workflows/v8-canary.yml` so changes to the shared Bazel setup action still run the canary workflow. - Kept the existing repository-cache and Windows-specific Bazel setup logic intact. This keeps Bazel version selection anchored by `.bazelversion` while removing the failing dependency on the archived setup action. ## Verification - Searched `.github/` to confirm there are no remaining `setup-bazelisk` references. - Parsed the updated workflow and action YAML locally with Ruby's `YAML.load_file`. |
||
|
Michael Bolin
|
c2084552d9 |
ci: pin npm staging smoke test to a recent rust-release run (#19854)
## Why The `build-test` workflow stages a representative `codex` npm tarball by asking `scripts/stage_npm_packages.py` to look up a past `rust-release` run for a hardcoded release version. That started failing in CI because the representative version in `.github/workflows/ci.yml` was stale: - the workflow was still using `0.115.0` - `stage_npm_packages.py` resolves native artifacts by looking for a `rust-release` run on the `rust-v<version>` branch - that lookup no longer found a matching run for `rust-v0.115.0`, so the smoke test failed before it could stage the package This PR makes that smoke test depend on a known-good recent release run instead of an older branch lookup that is no longer reliable. ## What Changed - Updated the representative release version in `.github/workflows/ci.yml` from `0.115.0` to `0.125.0`. - Added an explicit `WORKFLOW_URL` pointing at a recent successful `rust-release` run: `https://github.com/openai/codex/actions/runs/24901475298`. - Passed that URL to `scripts/stage_npm_packages.py` via `--workflow-url` so the job can reuse the expected native artifacts directly instead of relying on `gh run list --branch rust-v<version>` to discover them. That keeps the npm staging smoke test representative while making it less sensitive to older release branch history disappearing from the GitHub Actions lookup path. ## Verification - Inspected the failing CI log from `build-test` and confirmed the failure came from `scripts/stage_npm_packages.py` being unable to resolve `rust-v0.115.0`. - Confirmed that `https://github.com/openai/codex/actions/runs/24901475298` is a successful `rust-release` run for `rust-v0.125.0`. |
||
|
Shijie Rao
|
4e30281a13 |
Guard npm update readiness (#19389)
## Why For npm/Bun-managed installs, the update prompt was treating the latest GitHub release as ready to install. During the `0.124.0` release, GitHub and npm visibility were not atomic: the root npm wrapper could become visible before the npm registry marked that version as the package `latest`. That left a window where users could be prompted to upgrade before npm was ready for the release. ## What changed - Keep GitHub Releases as the candidate latest-version source for npm/Bun installs, but only write the existing `version.json` cache after npm registry metadata proves that same root version is ready. - Add `codex-rs/tui/src/npm_registry.rs` to validate npm readiness by checking `dist-tags.latest` and root package `dist` metadata for the GitHub candidate version. - Move version parsing helpers into `codex-rs/tui/src/update_versions.rs` so that logic can be tested without compiling the release-only `updates.rs` module under tests. - Update `.github/workflows/rust-release.yml` so the six known platform tarballs publish before the root `@openai/codex` wrapper. Other npm tarballs publish before the root wrapper, and the SDK publishes after the root package it depends on. |
||
|
Michael Bolin
|
9881dc7306 |
fix: restore 30-minute timeout for Bazel builds (#19609)
I think raising it to 45 minutes in https://github.com/openai/codex/pull/19578 was a mistake for the reasons explained in the comments in the code. Instead, we attempt to defend against timeouts by increasing the number of shards in `app-server-all-test` so that a "true failure" that gets run 3x should not take as much wall clock time. |
||
|
Michael Bolin
|
88f300d74d |
fix: increase Bazel timeout to 45 minutes (#19578)
Unfortunately, if most of the build graph is invalidated such that there are few cache hits, the Windows Bazel build for all the tests often takes more than `30` minutes, so this PR increases the timeout to `45` minutes until we set up distributed builds. |
||
|
Curtis 'Fjord' Hawthorne
|
8a559e7938 | Remove js_repl feature (#19410) | ||
|
viyatb-oai
|
1c3287125f |
ci: pin codex-action v1.7 (#19472)
## Summary - update Codex issue automation to pin `openai/codex-action` to `5c3f4ccdb2b8790f73d6b21751ac00e602aa0c02`, the commit for `v1.7` - keep the release intent visible with `# v1.7` comments beside the hash pins ## Test plan - `git diff --check` - `yq e '.' .github/workflows/issue-labeler.yml` - `yq e '.' .github/workflows/issue-deduplicator.yml` --------- Co-authored-by: Codex <noreply@openai.com> |
||
|
Michael Bolin
|
9b8a1fbefc |
ci: publish codex-app-server release artifacts (#19447)
## Why The VS Code extension and desktop app do not need the full TUI binary, and `codex-app-server` is materially smaller than standalone `codex`. We still want to publish it as an official release artifact, but building it by tacking another `--bin` onto the existing release `cargo build` invocations would lengthen those jobs. This change keeps `codex-app-server` on its own release bundle so it can build in parallel with the existing `codex` and helper bundles. ## What changed - Made `.github/workflows/rust-release.yml` bundle-aware so each macOS and Linux MUSL target now builds either the existing `primary` bundle (`codex` and `codex-responses-api-proxy`) or a standalone `app-server` bundle (`codex-app-server`). - Preserved the historical artifact names for the primary macOS/Linux bundles so `scripts/stage_npm_packages.py` and `codex-cli/scripts/install_native_deps.py` continue to find release assets under the paths they already expect, while giving the new app-server artifacts distinct names. - Added a matching `app-server` bundle to `.github/workflows/rust-release-windows.yml`, and updated the final Windows packaging job to download, sign, stage, and archive `codex-app-server.exe` alongside the existing release binaries. - Generalized the shared signing actions in `.github/actions/linux-code-sign/action.yml`, `.github/actions/macos-code-sign/action.yml`, and `.github/actions/windows-code-sign/action.yml` so each workflow row declares its binaries once and reuses that list for build, signing, and staging. - Added `codex-app-server` to `.github/dotslash-config.json` so releases also publish a generated DotSlash manifest for the standalone app-server binary. - Kept the macOS DMG focused on the existing `primary` bundle; `codex-app-server` ships as the regular standalone archives and DotSlash manifest. ## Verification - Parsed the modified workflow and action YAML files locally with `python3` + `yaml.safe_load(...)`. - Parsed `.github/dotslash-config.json` locally with `python3` + `json.loads(...)`. - Reviewed the resulting release matrices, artifact names, and packaging paths to confirm that `codex-app-server` is built separately on macOS, Linux MUSL, and Windows, while the existing npm staging and Windows `codex` zip bundling contracts remain intact. |
||
|
Michael Bolin
|
db94b1657b |
ci: stop publishing GNU Linux release artifacts (#19445)
## Why We already prefer shipping the MUSL Linux builds, and the in-repo release consumers resolve Linux release assets through the MUSL targets. Keeping the GNU release jobs around adds release time and extra assets without serving the paths we actually publish and consume. This is also easier to reason about as a standalone change: future work can point back to this PR as the intentional decision to stop publishing `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` release artifacts. ## What changed - Removed the `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` entries from the `build` matrix in `.github/workflows/rust-release.yml`. - Added a short comment in that matrix documenting that Linux release artifacts intentionally ship MUSL-linked binaries. ## Verification - Reviewed `.github/workflows/rust-release.yml` to confirm that the release workflow now only builds Linux release artifacts for `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl`. |
||
|
Michael Bolin
|
e8ba912fcc |
test: set Rust test thread stack size (#19067)
## Summary Set `RUST_MIN_STACK=8388608` for Rust test entry points so libtest-spawned test threads get an 8 MiB stack. The Windows BuildBuddy failure on #18893 showed `//codex-rs/tui:tui-unit-tests` exiting with a stack overflow in a `#[tokio::test]` even though later test binaries in the shard printed successful summaries. Default `#[tokio::test]` uses a current-thread Tokio runtime, which means the async test body is driven on libtest's std-spawned test thread. Increasing the test thread stack addresses that failure mode directly. To date, we have been fixing these stack-pressure problems with localized future-size reductions, such as #13429, and by adding `Box::pin()` in specific async wrapper chains. This gives us a baseline test-runner stack size instead of continuing to patch individual tests only after CI finds another large async future. ## What changed - Added `common --test_env=RUST_MIN_STACK=8388608` in `.bazelrc` so Bazel test actions receive the env var through Bazel's cache-keyed test environment path. - Set the same `RUST_MIN_STACK` value for Cargo/nextest CI entry points and `just test`. - Annotated the existing Windows Bazel linker stack reserve as 8 MiB so it stays aligned with the libtest thread stack size. ## Testing - `just --list` - parsed `.github/workflows/rust-ci.yml` and `.github/workflows/rust-ci-full.yml` with Ruby's YAML loader - compared `bazel aquery` `TestRunner` action keys before/after explicit `--test_env=RUST_MIN_STACK=...` and after moving the Bazel env to `.bazelrc` - `bazel test //codex-rs/tui:tui-unit-tests --test_output=errors` - failed locally on the existing sandbox-specific status snapshot permission mismatch, but loaded the Starlark changes and ran the TUI test shards |
||
|
Michael Bolin
|
03ae4db0f4 |
ci: keep argument comment lint checks materialized (#18926)
## Why
The fast `rust-ci` workflow decides whether to run the cross-platform
`argument-comment-lint` job based on changed paths. PRs that touch
Rust-adjacent Bazel wrapper files, such as `defs.bzl` or
`workspace_root_test_launcher.*.tpl`, can change how Rust tests and lint
targets behave without changing any `.rs` files.
When that detector returned false, GitHub skipped the matrix job before
expanding it. That produced a single skipped check named `Argument
comment lint - ${{ matrix.name }}` instead of the Linux, macOS, and
Windows check names that branch protection expects, leaving the PR
unable to go green when those matrix checks are required.
## What Changed
- Treat root Bazel wrapper files as `argument-comment-lint` relevant
changes.
- Keep the `argument_comment_lint_prebuilt` matrix job materialized for
every PR so the per-platform check names always exist.
- Add a single gate step that decides whether the real lint work should
run.
- Move the checkout-adjacent Bazel setup and OS-specific lint commands
into `.github/actions/run-argument-comment-lint/action.yml` so the
workflow does not repeat the same path-detection condition on each step.
## Verification
- Parsed `.github/workflows/rust-ci.yml` and
`.github/actions/run-argument-comment-lint/action.yml` with Python YAML
loading.
- Simulated the workflow path-matching shell conditions for the root
Bazel wrapper files and confirmed they set `argument_comment_lint=true`.
|
||
|
Ahmed Ibrahim
|
ed1c5013ab |
Remove unused models.json (#18585)
- Remove the stale core models catalog. - Update the release workflow to refresh the active models-manager catalog. |
||
|
Michael Bolin
|
29bc2ad2f4 |
ci: scope Bazel repository cache by job (#18366)
## Why
The Bazel workflow has multiple jobs that run concurrently for the same
target triple. In particular, the Windows `test`, `clippy`, and
`verify-release-build` jobs could all miss and then attempt to save the
same Bazel repository cache key:
```text
bazel-cache-${target}-${lockhash}
```
Because `actions/cache` entries are immutable, only one job can reserve
that key. The others can report failures such as:
```text
Failed to save: Unable to reserve cache with key bazel-cache-x86_64-pc-windows-gnullvm-..., another job may be creating this cache.
```
Adding only the workflow name would not separate these jobs because they
all run inside the same `Bazel` workflow. The key needs a job-level
namespace as well.
## What Changed
- Added a required `cache-scope` input to
`.github/actions/prepare-bazel-ci/action.yml`.
- Moved Bazel repository cache key construction into the shared action
and exposed the computed key as `repository-cache-key`.
- Exposed the exact restore result as `repository-cache-hit` so save
steps can skip exact cache hits.
- Updated `.github/workflows/bazel.yml` to pass `cache-scope: bazel-${{
github.job }}` for the `test`, `clippy`, and `verify-release-build`
jobs.
- The scoped restore key is now the only fallback. This avoids carrying
a temporary restore path for the old unscoped cache namespace.
## Verification
- Parsed `.github/actions/prepare-bazel-ci/action.yml` and
`.github/workflows/bazel.yml` with Ruby's YAML parser.
- `actionlint` is not installed in this workspace, so I could not run a
GitHub Actions semantic lint locally.
|
||
|
Michael Bolin
|
2c2ed51876 |
ci: make Windows Bazel clippy catch core test imports (#18350)
## Why Unused imports in `core/tests/suite/unified_exec.rs` in the Windows build were not caught by Bazel CI on https://github.com/openai/codex/pull/18096. I spot-checked https://github.com/openai/codex/actions/workflows/rust-ci-full.yml?query=branch%3Amain and noticed that builds were consistently red. This revealed that our Cargo builds _were_ properly catching these issues, identifying a Windows-specific coverage hole in the Bazel clippy job. The Windows Bazel clippy job uses `--skip_incompatible_explicit_targets` so it can lint a broad target set without failing immediately on targets that are genuinely incompatible with Windows. However, with the default Windows host platform, `rust_test` targets such as `//codex-rs/core:core-all-test` could be skipped before the clippy aspect reached their integration-test modules. As a result, the imports in `core/tests/suite/unified_exec.rs` were not being linted by the Windows Bazel clippy job at all. The clippy diagnostic that Windows Bazel should have surfaced was: ```text error: unused import: `codex_config::Constrained` --> core\tests\suite\unified_exec.rs:8:5 | 8 | use codex_config::Constrained; | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unused-imports` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_imports)]` error: unused import: `codex_protocol::permissions::FileSystemAccessMode` --> core\tests\suite\unified_exec.rs:11:5 | 11 | use codex_protocol::permissions::FileSystemAccessMode; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemPath` --> core\tests\suite\unified_exec.rs:12:5 | 12 | use codex_protocol::permissions::FileSystemPath; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemSandboxEntry` --> core\tests\suite\unified_exec.rs:13:5 | 13 | use codex_protocol::permissions::FileSystemSandboxEntry; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemSandboxPolicy` --> core\tests\suite\unified_exec.rs:14:5 | 14 | use codex_protocol::permissions::FileSystemSandboxPolicy; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` ## What changed - Run the Windows Bazel clippy job with the MSVC host platform via `--windows-msvc-host-platform`, matching the Windows Bazel test job. This keeps `--skip_incompatible_explicit_targets` while ensuring Windows `rust_test` targets such as `//codex-rs/core:core-all-test` are still linted. - Remove the unused imports from `core/tests/suite/unified_exec.rs`. - Add `--print-failed-action-summary` to `.github/scripts/run-bazel-ci.sh` so Bazel action failures can be summarized after the build exits. ## Failure reporting Once the coverage issue was fixed, an intentionally reintroduced unused import made the Windows Bazel clippy job fail as expected. That exposed a separate usability problem: because the job keeps `--keep_going`, the top-level Bazel output could still end with: ```text ERROR: Build did NOT complete successfully FAILED: ``` without the underlying rustc/clippy diagnostic being visible in the obvious part of the GitHub Actions log. To keep `--keep_going` while making failures actionable, the wrapper now scans the captured Bazel console output for failed actions and prints the matching rustc/clippy diagnostic block. When a diagnostic block is found, it is emitted both as a GitHub `::error` annotation and as plain expanded log output, rather than being hidden in a collapsed group. ## Verification To validate the CI path, I intentionally introduced an unused import in `core/tests/suite/unified_exec.rs`. The Windows Bazel clippy job failed as expected, confirming that the integration-test module is now covered by Bazel clippy. The same failure also verified that the wrapper surfaces the matching clippy diagnostics directly in the Actions output. |
||
|
starr-openai
|
3905f72891 |
Throttle Windows Bazel test concurrency (#18192)
## Summary - cap the Windows Bazel test lane at `--jobs=8` to reduce local runner pressure - keep Linux and macOS Bazel test concurrency unchanged - make failed-test log tailing resolve `bazel-testlogs` with the same CI config and Windows host-platform context as the failed invocation - prefer Bazel-reported `test.log` paths and normalize Windows path separators before tailing ## Context The Windows Bazel workflow currently uses `ci-windows`, which does not inherit the remote executor config. This means the lane runs the `//...` test suite locally and otherwise falls back to the repo-wide `common --jobs=30`. The new Windows-only override is intended to reduce local executor pressure without changing coverage. ## Validation Not run locally; this is a CI workflow change and the draft PR is intended to exercise the GitHub Actions lane directly. --------- Co-authored-by: Codex <noreply@openai.com> |
||
|
evawong-oai
|
17d94bd1e3 |
[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
|
0bb438bca6 |
[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. |
||
|
starr-openai
|
e063596c67 |
Reuse remote exec-server in core tests (#17837)
## Summary - reuse a shared remote exec-server for remote-aware codex-core integration tests within a test binary process - keep per-test remote cwd creation and cleanup so tests retain workspace isolation - leave codex_self_exe, codex_linux_sandbox_exe, cwd_path(), and workspace_path() behavior unchanged ## Validation - rustfmt codex-rs/core/tests/common/test_codex.rs - git diff --check - CI is running on the updated branch |
||
|
Michael Bolin
|
5ecaf09ab0 |
Add Bazel verify-release-build job (#17705)
## Why `main` recently needed [#17691](https://github.com/openai/codex/pull/17691) because code behind `cfg(not(debug_assertions))` was not being compiled by the Bazel PR workflow. Our existing CI only built the fast/debug configuration, so PRs could stay green while release-only Rust code still failed to compile. This PR adds a release-style compile check that is cheap enough to run on every PR. ## What Changed - Added a `verify-release-build` job to `.github/workflows/bazel.yml`. - Represented each supported OS once in that job's matrix: x64 Linux, arm64 macOS, and x64 Windows. - Kept the build close to fastbuild cost by using `--compilation_mode=fastbuild` while forcing Rust to compile with `-Cdebug-assertions=no`, which makes `cfg(not(debug_assertions))` true without also turning on release optimizations or debug-info generation. - Added comments in `.github/workflows/bazel.yml` and `scripts/list-bazel-release-targets.sh` to make the job's intent and target scope explicit. - Restored the Bazel repository cache save behavior to run after every non-cancelled job, matching [#16926](https://github.com/openai/codex/pull/16926), and removed the now-unused `repository-cache-hit` output from `prepare-bazel-ci`. - Reused the shared `prepare-bazel-ci` action from the parent PR so the new job does not duplicate Bazel setup boilerplate. ## Verification - Used `bazel aquery` on `//codex-rs/tui:codex-tui` to confirm the Rust compile still uses `opt-level=0` and `debuginfo=0` while passing `-Cdebug-assertions=no`. - Parsed `.github/workflows/bazel.yml` as YAML locally. - Ran `bash -n scripts/list-bazel-release-targets.sh`. |
||
|
Michael Bolin
|
440597c7e7 |
Refactor Bazel CI job setup (#17704)
## Why This stack adds a new Bazel CI lane that verifies Rust code behind `cfg(not(debug_assertions))`, but adding that job directly to `.github/workflows/bazel.yml` would duplicate the same setup in multiple places. Extracting the shared setup first keeps the follow-up change easier to review and reduces the chance that future Bazel workflow edits drift apart. ## What Changed - Added `.github/actions/prepare-bazel-ci/action.yml` as a composite action for the Bazel job bootstrap shared by multiple workflow jobs. - Moved the existing Bazel setup, repository-cache restore, and execution-log setup behind that action. - Updated the `test` and `clippy` jobs in `.github/workflows/bazel.yml` to call `prepare-bazel-ci`. - Exposed `repository-cache-hit` and `repository-cache-path` outputs so callers can keep the existing cache-save behavior without duplicating the restore step. ## Verification - Parsed `.github/workflows/bazel.yml` as YAML locally after rebasing the stack. - CI will exercise the refactored jobs end to end. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17704). * #17705 * __->__ #17704 |
||
|
viyatb-oai
|
d9a385ac8c |
fix: pin inputs (#17471)
## Summary - Pin Rust git patch dependencies to immutable revisions and make cargo-deny reject unknown git and registry sources unless explicitly allowlisted. - Add checked-in SHA-256 coverage for the current rusty_v8 release assets, wire those hashes into Bazel, and verify CI override downloads before use. - Add rusty_v8 MODULE.bazel update/check tooling plus a Bazel CI guard so future V8 bumps cannot drift from the checked-in checksum manifest. - Pin release/lint cargo installs and all external GitHub Actions refs to immutable inputs. ## Future V8 bump flow Run these after updating the resolved `v8` crate version and checksum manifest: ```bash python3 .github/scripts/rusty_v8_bazel.py update-module-bazel python3 .github/scripts/rusty_v8_bazel.py check-module-bazel ``` The update command rewrites the matching `rusty_v8_<crate_version>` `http_file` SHA-256 values in `MODULE.bazel` from `third_party/v8/rusty_v8_<crate_version>.sha256`. The check command is also wired into Bazel CI to block drift. ## Notes - This intentionally excludes RustSec dependency upgrades and bubblewrap-related changes per request. - The branch was rebased onto the latest origin/main before opening the PR. ## Validation - cargo fetch --locked - cargo deny check advisories - cargo deny check - cargo deny check sources - python3 .github/scripts/rusty_v8_bazel.py check-module-bazel - python3 .github/scripts/rusty_v8_bazel.py update-module-bazel - python3 -m unittest discover -s .github/scripts -p 'test_rusty_v8_bazel.py' - python3 -m py_compile .github/scripts/rusty_v8_bazel.py .github/scripts/rusty_v8_module_bazel.py .github/scripts/test_rusty_v8_bazel.py - repo-wide GitHub Actions `uses:` audit: all external action refs are pinned to 40-character SHAs - yq eval on touched workflows and local actions - git diff --check - just bazel-lock-check ## Hash verification - Confirmed `MODULE.bazel` hashes match `third_party/v8/rusty_v8_146_4_0.sha256`. - Confirmed GitHub release asset digests for denoland/rusty_v8 `v146.4.0` and openai/codex `rusty-v8-v146.4.0` match the checked-in hashes. - Streamed and SHA-256 hashed all 10 `MODULE.bazel` rusty_v8 asset URLs locally; every downloaded byte stream matched both `MODULE.bazel` and the checked-in manifest. ## Pin verification - Confirmed signing-action pins match the peeled commits for their tag comments: `sigstore/cosign-installer@v3.7.0`, `azure/login@v2`, and `azure/trusted-signing-action@v0`. - Pinned the remaining tag-based action refs in Bazel CI/setup: `actions/setup-node@v6`, `facebook/install-dotslash@v2`, `bazelbuild/setup-bazelisk@v3`, and `actions/cache/restore@v5`. - Normalized all `bazelbuild/setup-bazelisk@v3` refs to the peeled commit behind the annotated tag. - Audited Cargo git dependencies: every manifest git dependency uses `rev` only, every `Cargo.lock` git source has `?rev=<sha>#<same-sha>`, and `cargo deny check sources` passes with `required-git-spec = "rev"`. - Shallow-fetched each distinct git dependency repo at its pinned SHA and verified Git reports each object as a commit. |
||
|
Eric Traut
|
640d3a036f |
Update issue labeler agent labels (#17483)
Problem: The automatic issue labeler still treated agent-related issues as one broad category, even though more specific agent-area labels now exist. Solution: Update the issue labeler prompt to prefer the new agent-area labels and keep "agent" as the fallback for uncategorized core agent issues. |
||
|
Eric Traut
|
66e13efd9c |
TUI: enforce core boundary (#17399)
Problem: The TUI still depended on `codex-core` directly in a number of places, and we had no enforcement from keeping this problem from getting worse. Solution: Route TUI core access through `codex-app-server-client::legacy_core`, add CI enforcement for that boundary, and re-export this legacy bridge inside the TUI as `crate::legacy_core` so the remaining call sites stay readable. There is no functional change in this PR — just changes to import targets. Over time, we can whittle away at the remaining symbols in this legacy namespace with the eventual goal of removing them all. In the meantime, this linter rule will prevent us from inadvertently importing new symbols from core. |
||
|
Eric Traut
|
abc678f9e8 |
Remove obsolete codex-cli README (#17096)
Problem: codex-cli/README.md is obsolete and confusing to keep around. Solution: Delete codex-cli/README.md so the stale README is no longer present in the repository. |
||
|
pakrym-oai
|
470b3592e6 |
Add full-ci branch trigger (#16980)
Allow branches to trigger full ci (helpful to run remote tests) |
||
|
Ruslan Nigmatullin
|
0225479f0d |
bazel: Always save bazel repository cache (#16926)
This should improve the cache hit ratio for external deps and such |
||
|
Michael Bolin
|
39097ab65d |
ci: align Bazel repo cache and Windows clippy target handling (#16740)
## Why Bazel CI had two independent Windows issues: - The workflow saved/restored `~/.cache/bazel-repo-cache`, but `.bazelrc` configured `common:ci-windows --repository_cache=D:/a/.cache/bazel-repo-cache`, so `actions/cache` and Bazel could point at different directories. - The Windows `Bazel clippy` job passed the full explicit target list from `//codex-rs/...`, but some of those explicit targets are intentionally incompatible with `//:local_windows`. `run-argument-comment-lint-bazel.sh` already handles that with `--skip_incompatible_explicit_targets`; the clippy workflow path did not. I also tried switching the workflow cache path to `D:\a\.cache\bazel-repo-cache`, but the Windows clippy job repeatedly failed with `Failed to restore: Cache service responded with 400`, so the final change standardizes on `$HOME/.cache/bazel-repo-cache` and makes cache restore non-fatal. ## What Changed - Expose one repository-cache path from `.github/actions/setup-bazel-ci/action.yml` and export that path as `BAZEL_REPOSITORY_CACHE` so `run-bazel-ci.sh` passes it to Bazel after `--config=ci-*`. - Move `actions/cache/restore` out of the composite action into `.github/workflows/bazel.yml`, and make restore failures non-fatal there. - Save exactly the exported cache path in `.github/workflows/bazel.yml`. - Remove `common:ci-windows --repository_cache=D:/a/.cache/bazel-repo-cache` from `.bazelrc` so the Windows CI config no longer disagrees with the workflow cache path. - Pass `--skip_incompatible_explicit_targets` in the Windows `Bazel clippy` job so incompatible explicit targets do not fail analysis while the lint aspect still traverses compatible Rust dependencies. ## Verification - Parsed `.github/actions/setup-bazel-ci/action.yml` and `.github/workflows/bazel.yml` with Ruby's YAML loader. - Resubmitted PR `#16740`; CI is rerunning on the amended commit. |
||
|
Michael Bolin
|
c9e706f8b6 |
Back out "bazel: lint rust_test targets in clippy workflow (#16450)" (#16757)
This backs out https://github.com/openai/codex/pull/16450 because it was not good to go yet. |
||
|
Ahmed Ibrahim
|
13d828d236 |
Use Node 24 for npm publish (#16755)
Avoid self-upgrading the runner's bundled npm in release publishing; Node 24 already provides an npm CLI that supports trusted publishing. Co-authored-by: Codex <noreply@openai.com> |
||
|
Michael Bolin
|
f263607c60 |
bazel: lint rust_test targets in clippy workflow (#16450)
## Why `cargo clippy --tests` was catching warnings in inline `#[cfg(test)]` code that the Bazel PR Clippy lane missed. The existing Bazel invocation linted `//codex-rs/...`, but that did not apply Clippy to the generated manual `rust_test` binaries, so warnings in targets such as `//codex-rs/state:state-unit-tests-bin` only surfaced as plain compile warnings instead of failing the lint job. ## What Changed - added `scripts/list-bazel-clippy-targets.sh` to expand the Bazel Clippy target set with the generated manual `rust_test` rules while still excluding `//codex-rs/v8-poc:all` - updated `.github/workflows/bazel.yml` to use that expanded target list in the Bazel Clippy PR job - updated `just bazel-clippy` to use the same target expansion locally - updated `.github/workflows/README.md` to document that the Bazel PR lint lane now covers inline `#[cfg(test)]` code ## Verification - `./scripts/list-bazel-clippy-targets.sh` includes `//codex-rs/state:state-unit-tests-bin` - `bazel build --config=clippy -- //codex-rs/state:state-unit-tests-bin` now fails with the same unused import in `state/src/runtime/logs.rs` that `cargo clippy --tests` reports |
||
|
Michael Bolin
|
eaf12beacf |
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. |
||
|
Eric Traut
|
f5d39a88ce | Fixed some existing labels and added a few new ones (#16616) | ||
|
Michael Bolin
|
a098834148 |
ci: upload compact Bazel execution logs for bazel.yml (#16577)
## Why The main Bazel CI lanes need compact execution logs to investigate cache misses and unexpected rebuilds, but local users of the shared wrapper should not pay that log-generation cost by default. ## What Changed - [`.github/scripts/run-bazel-ci.sh`]( |
||
|
Michael Bolin
|
148dbb25f0 |
ci: stop running rust CI with --all-features (#16473)
## Why Now that workspace crate features have been removed and `.github/scripts/verify_cargo_workspace_manifests.py` hard-bans new ones, Rust CI should stop building and testing with `--all-features`. Keeping `--all-features` in CI no longer buys us meaningful coverage for `codex-rs`, but it still makes the workflow look like we rely on Cargo feature permutations that we are explicitly trying to eliminate. It also leaves stale examples in the repo that suggest `--all-features` is a normal or recommended way to run the workspace. ## What changed - removed `--all-features` from the Rust CI `cargo chef cook`, `cargo clippy`, and `cargo nextest` invocations in `.github/workflows/rust-ci-full.yml` - updated the `just test` guidance in `justfile` to reflect that workspace crate features are banned and there should be no need to add `--all-features` - updated the multiline command example and snapshot in `codex-rs/tui/src/history_cell.rs` to stop rendering `cargo test --all-features --quiet` - tightened the verifier docstring in `.github/scripts/verify_cargo_workspace_manifests.py` so it no longer talks about temporary remaining exceptions ## How tested - `python3 .github/scripts/verify_cargo_workspace_manifests.py` - `cargo test -p codex-tui` |
||
|
Michael Bolin
|
2e942ce830 |
ci: sync Bazel clippy lints and fix uncovered violations (#16351)
## Why Follow-up to #16345, the Bazel clippy rollout in #15955, and the cleanup pass in #16353. `cargo clippy` was enforcing the workspace deny-list from `codex-rs/Cargo.toml` because the member crates opt into `[lints] workspace = true`, but Bazel clippy was only using `rules_rust` plus `clippy.toml`. That left the Bazel lane vulnerable to drift: `clippy.toml` can tune lint behavior, but it cannot set allow/warn/deny/forbid levels. This PR now closes both sides of the follow-up. It keeps `.bazelrc` in sync with `[workspace.lints.clippy]`, and it fixes the real clippy violations that the newly-synced Windows Bazel lane surfaced once that deny-list started matching Cargo. ## What Changed - added `.github/scripts/verify_bazel_clippy_lints.py`, a Python check that parses `codex-rs/Cargo.toml` with `tomllib`, reads the Bazel `build:clippy` `clippy_flag` entries from `.bazelrc`, and reports missing, extra, or mismatched lint levels - ran that verifier from the lightweight `ci.yml` workflow so the sync check does not depend on a Rust toolchain being installed first - expanded the `.bazelrc` comment to explain the Cargo `workspace = true` linkage and why Bazel needs the deny-list duplicated explicitly - fixed the Windows-only `codex-windows-sandbox` violations that Bazel clippy reported after the sync, using the same style as #16353: inline `format!` args, method references instead of trivial closures, removed redundant clones, and replaced SID conversion `unwrap` and `expect` calls with proper errors - cleaned up the remaining cross-platform violations the Bazel lane exposed in `codex-backend-client` and `core_test_support` ## Testing Key new test introduced by this PR: `python3 .github/scripts/verify_bazel_clippy_lints.py` |
||
|
Michael Bolin
|
9a8730f31e |
ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)
## Why Bazel clippy now catches lints that `cargo clippy` can still miss when a crate under `codex-rs` forgets to opt into workspace lints. The concrete example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel flagged a clippy violation in `models_cache.rs`, but Cargo did not because that crate inherited workspace package metadata without declaring `[lints] workspace = true`. We already mirror the workspace clippy deny list into Bazel after [#15955](https://github.com/openai/codex/pull/15955), so we also need a repo-side check that keeps every `codex-rs` manifest opted into the same workspace settings. ## What changed - add `.github/scripts/verify_cargo_workspace_manifests.py`, which parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies: - `version.workspace = true` - `edition.workspace = true` - `license.workspace = true` - `[lints] workspace = true` - top-level crate names follow the `codex-*` / `codex-utils-*` conventions, with explicit exceptions for `windows-sandbox-rs` and `utils/path-utils` - run that script in `.github/workflows/ci.yml` - update the current outlier manifests so the check is enforceable immediately - fix the newly exposed clippy violations in the affected crates (`app-server/tests/common`, `file-search`, `feedback`, `shell-escalation`, and `debug-client`) --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353). * #16351 * __->__ #16353 |
||
|
Michael Bolin
|
19f0d196d1 |
ci: run Windows argument-comment-lint via native Bazel (#16120)
## Why Follow-up to #16106. `argument-comment-lint` already runs as a native Bazel aspect on Linux and macOS, but Windows is still the long pole in `rust-ci`. To move Windows onto the same native Bazel lane, the toolchain split has to let exec-side helper binaries build in an MSVC environment while still linting repo crates as `windows-gnullvm`. Pushing the Windows lane onto the native Bazel path exposed a second round of Windows-only issues in the mixed exec-toolchain plumbing after the initial wrapper/target fixes landed. ## What Changed - keep the Windows lint lanes on the native Bazel/aspect path in `rust-ci.yml` and `rust-ci-full.yml` - add a dedicated `local_windows_msvc` platform for exec-side helper binaries while keeping `local_windows` as the `windows-gnullvm` target platform - patch `rules_rust` so `repository_set(...)` preserves explicit exec-platform constraints for the generated toolchains, keep the Windows-specific bootstrap/direct-link fixes needed for the nightly lint driver, and expose exec-side `rustc-dev` `.rlib`s to the MSVC sysroot - register the custom Windows nightly toolchain set with MSVC exec constraints while still exposing both `x86_64-pc-windows-msvc` and `x86_64-pc-windows-gnullvm` targets - enable `dev_components` on the custom Windows nightly repository set so the MSVC exec helper toolchain actually downloads the compiler-internal crates that `clippy_utils` needs - teach `run-argument-comment-lint-bazel.sh` to enumerate concrete Windows Rust rules, normalize the resulting labels, and skip explicitly requested incompatible targets instead of failing before the lint run starts - patch `rules_rust` build-script env propagation so exec-side `windows-msvc` helper crates drop forwarded MinGW include and linker search paths as whole flag/path pairs instead of emitting malformed `CFLAGS`, `CXXFLAGS`, and `LDFLAGS` - export the Windows VS/MSVC SDK environment in `setup-bazel-ci` and pass the relevant variables through `run-bazel-ci.sh` via `--action_env` / `--host_action_env` so Bazel build scripts can see the MSVC and UCRT headers on native Windows runs - add inline comments to the Windows `setup-bazel-ci` MSVC environment export step so it is easier to audit how `vswhere`, `VsDevCmd.bat`, and the filtered `GITHUB_ENV` export fit together - patch `aws-lc-sys` to skip its standalone `memcmp` probe under Bazel `windows-msvc` build-script environments, which avoids a Windows-native toolchain mismatch that blocked the lint lane before it reached the aspect execution - patch `aws-lc-sys` to prefer its bundled `prebuilt-nasm` objects for Bazel `windows-msvc` build-script runs, which avoids missing `generated-src/win-x86_64/*.asm` runfiles in the exec-side helper toolchain - annotate the Linux test-only callsites in `codex-rs/linux-sandbox` and `codex-rs/core` that the wider native lint coverage surfaced ## Patches This PR introduces a large patch stack because the Windows Bazel lint lane currently depends on behavior that upstream dependencies do not provide out of the box in the mixed `windows-gnullvm` target / `windows-msvc` exec-toolchain setup. - Most of the `rules_rust` patches look like upstream candidates rather than OpenAI-only policy. Preserving explicit exec-platform constraints, forwarding the right MSVC/UCRT environment into exec-side build scripts, exposing exec-side `rustc-dev` artifacts, and keeping the Windows bootstrap/linker behavior coherent all look like fixes to the Bazel/Rust integration layer itself. - The two `aws-lc-sys` patches are more tactical. They special-case Bazel `windows-msvc` build-script environments to avoid a `memcmp` probe mismatch and missing NASM runfiles. Those may be harder to upstream as-is because they rely on Bazel-specific detection instead of a general Cargo/build-script contract. - Short term, carrying these patches in-tree is reasonable because they unblock a real CI lane and are still narrow enough to audit. Long term, the goal should not be to keep growing a permanent local fork of either dependency. - My current expectation is that the `rules_rust` patches are less controversial and should be broken out into focused upstream proposals, while the `aws-lc-sys` patches are more likely to be temporary escape hatches unless that crate wants a more general hook for hermetic build systems. Suggested follow-up plan: 1. Split the `rules_rust` deltas into upstream-sized PRs or issues with minimized repros. 2. Revisit the `aws-lc-sys` patches during the next dependency bump and see whether they can be replaced by an upstream fix, a crate upgrade, or a cleaner opt-in mechanism. 3. Treat each dependency update as a chance to delete patches one by one so the local patch set only contains still-needed deltas. ## Verification - `./.github/scripts/run-argument-comment-lint-bazel.sh --config=argument-comment-lint --keep_going` - `RUNNER_OS=Windows ./.github/scripts/run-argument-comment-lint-bazel.sh --nobuild --config=argument-comment-lint --platforms=//:local_windows --keep_going` - `cargo test -p codex-linux-sandbox` - `cargo test -p codex-core shell_snapshot_tests` - `just argument-comment-lint` ## References - #16106 |
||
|
Michael Bolin
|
9313c49e4c |
fix: close Bazel argument-comment-lint CI gaps (#16253)
## Why The Bazel-backed `argument-comment-lint` CI path had two gaps: - Bazel wildcard target expansion skipped inline unit-test crates from `src/` modules because the generated `*-unit-tests-bin` `rust_test` targets are tagged `manual`. - `argument-comment-mismatch` was still only a warning in the Bazel and packaged-wrapper entrypoints, so a typoed `/*param_name*/` comment could still pass CI even when the lint detected it. That left CI blind to real linux-sandbox examples, including the missing `/*local_port*/` comment in `codex-rs/linux-sandbox/src/proxy_routing.rs` and typoed argument comments in `codex-rs/linux-sandbox/src/landlock.rs`. ## What Changed - Added `tools/argument-comment-lint/list-bazel-targets.sh` so Bazel lint runs cover `//codex-rs/...` plus the manual `rust_test` `*-unit-tests-bin` targets. - Updated `just argument-comment-lint`, `rust-ci.yml`, and `rust-ci-full.yml` to use that helper. - Promoted both `argument-comment-mismatch` and `uncommented-anonymous-literal-argument` to errors in every strict entrypoint: - `tools/argument-comment-lint/lint_aspect.bzl` - `tools/argument-comment-lint/src/bin/argument-comment-lint.rs` - `tools/argument-comment-lint/wrapper_common.py` - Added wrapper/bin coverage for the stricter lint flags and documented the behavior in `tools/argument-comment-lint/README.md`. - Fixed the now-covered callsites in `codex-rs/linux-sandbox/src/proxy_routing.rs`, `codex-rs/linux-sandbox/src/landlock.rs`, and `codex-rs/core/src/shell_snapshot_tests.rs`. This keeps the Bazel target expansion narrow while making the Bazel and prebuilt-linter paths enforce the same strict lint set. ## Verification - `python3 -m unittest discover -s tools/argument-comment-lint -p 'test_*.py'` - `cargo +nightly-2025-09-18 test --manifest-path tools/argument-comment-lint/Cargo.toml` - `just argument-comment-lint` |
||
|
Michael Bolin
|
a16a9109d7 |
ci: use BuildBuddy for rust-ci-full non-Windows argument-comment-lint (#16136)
## Why PR #16130 fixed the Windows `argument-comment-lint` regression in `rust-ci-full`, but the next `main` runs still left the Linux and macOS lint legs timing out. In [run 23695263729](https://github.com/openai/codex/actions/runs/23695263729), both non-Windows `argument-comment-lint` jobs were cancelled almost exactly 30 minutes after they started. The remaining workflow difference versus `rust-ci.yml` was that `rust-ci-full` did not pass `BUILDBUDDY_API_KEY` into the non-Windows Bazel lint step, so `run-bazel-ci.sh` fell back to local Bazel configuration instead of using the faster remote-backed path available on `main`. ## What changed - passed `BUILDBUDDY_API_KEY` to the non-Windows `rust-ci-full` `argument-comment-lint` Bazel step - left the Windows packaged-wrapper path from #16130 unchanged - kept the change scoped to `rust-ci-full.yml` ## Test plan - loaded `.github/workflows/rust-ci-full.yml` and `.github/workflows/rust-ci.yml` with `python3` + `yaml.safe_load(...)` - inspected run `23695263729` and confirmed `Argument comment lint - Linux` and `Argument comment lint - macOS` were cancelled about 30 minutes after start - verified the updated `rust-ci-full` step now matches the non-Windows secret wiring already present in `rust-ci.yml` ## References - #16130 - #16106 |
||
|
Michael Bolin
|
313fb95989 |
ci: keep rust-ci-full Windows argument-comment-lint on packaged wrapper (#16130)
## Why PR #16106 switched `rust-ci-full` over to the native Bazel-backed `argument-comment-lint` path on all three platforms. That works on Linux and macOS, but the Windows leg in `rust-ci-full` now fails before linting starts: Bazel dies while building `rules_rust`'s `process_wrapper` tool, so `main` reports an `argument-comment-lint` failure even though no Rust lint finding was produced. Until native Windows Bazel linting is repaired, `rust-ci-full` should keep the same Windows split that `rust-ci.yml` already uses. ## What changed - restored the Windows-only nightly `argument-comment-lint` toolchain setup in `rust-ci-full` - limited the Bazel-backed lint step in `rust-ci-full` to non-Windows runners - routed the Windows runner back through `tools/argument-comment-lint/run-prebuilt-linter.py` - left the Linux and macOS `rust-ci-full` behavior unchanged ## Test plan - loaded `.github/workflows/rust-ci-full.yml` and `.github/workflows/rust-ci.yml` with `python3` + `yaml.safe_load(...)` - inspected failing Actions run `23692864849`, especially job `69023229311`, to confirm the Windows failure occurs in Bazel `process_wrapper` setup before lint output is emitted ## References - #16106 |
||
|
Michael Bolin
|
fce0f76d57 |
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
|
b94366441e |
ci: split fast PR Rust CI from full post-merge Cargo CI (#16072)
## Summary
Split the old all-in-one `rust-ci.yml` into:
- a PR-time Cargo workflow in `rust-ci.yml`
- a full post-merge Cargo workflow in `rust-ci-full.yml`
This keeps the PR path focused on fast Cargo-native hygiene plus the
Bazel `build` / `test` / `clippy` coverage in `bazel.yml`, while moving
the heavyweight Cargo-native matrix to `main`.
## Why
`bazel.yml` is now the main Rust verification workflow for pull
requests. It already covers the Bazel build, test, and clippy signal we
care about pre-merge, and it also runs on pushes to `main` to re-verify
the merged tree and help keep the BuildBuddy caches warm.
What was still missing was a clean split for the Cargo-native checks
that Bazel does not replace yet. The old `rust-ci.yml` mixed together:
- fast hygiene checks such as `cargo fmt --check` and `cargo shear`
- `argument-comment-lint`
- the full Cargo clippy / nextest / release-build matrix
That made every PR pay for the full Cargo matrix even though most of
that coverage is better treated as post-merge verification. The goal of
this change is to leave PRs with the checks we still want before merge,
while moving the heavier Cargo-native matrix off the review path.
## What Changed
- Renamed the old heavyweight workflow to `rust-ci-full.yml` and limited
it to `push` on `main` plus `workflow_dispatch`.
- Added a new PR-only `rust-ci.yml` that runs:
- changed-path detection
- `cargo fmt --check`
- `cargo shear`
- `argument-comment-lint` on Linux, macOS, and Windows
- `tools/argument-comment-lint` package tests when the lint itself or
its workflow wiring changes
- Kept the PR workflow's gatherer as the single required Cargo-native
status so branch protection can stay simple.
- Added `.github/workflows/README.md` to document the intended split
between `bazel.yml`, `rust-ci.yml`, and `rust-ci-full.yml`.
- Preserved the recent Windows `argument-comment-lint` behavior from
`e02fd6e1d3` in `rust-ci-full.yml`, and mirrored cross-platform lint
coverage into the PR workflow.
A few details are deliberate:
- The PR workflow still keeps the Linux lint lane on the
default-targets-only invocation for now, while macOS and Windows use the
broader released-linter path.
- This PR does not change `bazel.yml`; it changes the Cargo-native
workflow around the existing Bazel PR path.
## Testing
- Rebasing this change onto `main` after `e02fd6e1d3`
- `ruby -e 'require "yaml"; %w[.github/workflows/rust-ci.yml
.github/workflows/rust-ci-full.yml .github/workflows/bazel.yml].each {
|f| YAML.load_file(f) }'`
|
||
|
Michael Bolin
|
e02fd6e1d3 |
fix: clean up remaining Windows argument-comment-lint violations (#16071)
## Why The initial `argument-comment-lint` rollout left Windows on default-target coverage because there were still Windows-only callsites failing under `--all-targets`. This follow-up cleans up those remaining Windows-specific violations so the Windows CI lane can enforce the same stricter coverage, leaving Linux as the remaining platform-specific follow-up. ## What changed - switched the Windows `rust-ci` argument-comment-lint step back to the default wrapper invocation so it runs full-target coverage again - added the required `/*param_name*/` annotations at Windows-gated literal callsites in: - `codex-rs/windows-sandbox-rs/src/lib.rs` - `codex-rs/windows-sandbox-rs/src/elevated_impl.rs` - `codex-rs/tui_app_server/src/multi_agents.rs` - `codex-rs/network-proxy/src/proxy.rs` ## Validation - Windows `argument comment lint` CI on this PR |