263 Commits

• Add v8-poc consumer of our new built v8 (#15203)

  This adds a dummy v8-poc project that in Cargo links against our
  prebuilt binaries and the ones provided by rusty_v8 for non musl
  platforms. This demonstrates that we can successfully link and use v8 on
  all platforms that we want to target.
  
  In bazel things are slightly more complicated. Since the libraries as
  published have libc++ linked in already we end up with a lot of double
  linked symbols if we try to use them in bazel land. Instead we fall back
  to building rusty_v8 and v8 from source (cached of course) on the
  platforms we ship to.
  
  There is likely some compatibility drift in the windows bazel builder
  that we'll need to reconcile before we can re-enable them. I'm happy to
  be on the hook to unwind that.

  Channing Conger · 2026-03-20 12:08:25 -07:00
  1350477150
• Add remote env CI matrix and integration test (#14869)

  `CODEX_TEST_REMOTE_ENV` will make `test_codex` start the executor
  "remotely" (inside a docker container) turning any integration test into
  remote test.

  pakrym-oai · 2026-03-20 08:02:50 -07:00
  ba85a58039
• Use released DotSlash package for argument-comment lint (#15199)

  ## Why
  The argument-comment lint now has a packaged DotSlash artifact from
  [#15198](https://github.com/openai/codex/pull/15198), so the normal repo
  lint path should use that released payload instead of rebuilding the
  lint from source every time.
  
  That keeps `just clippy` and CI aligned with the shipped artifact while
  preserving a separate source-build path for people actively hacking on
  the lint crate.
  
  The current alpha package also exposed two integration wrinkles that the
  repo-side prebuilt wrapper needs to smooth over:
  - the bundled Dylint library filename includes the host triple, for
  example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
  `RUSTUP_TOOLCHAIN` from that filename
  - on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
  present in the environment
  
  Without those adjustments, the prebuilt CI jobs fail during `cargo
  metadata` or driver setup. This change makes the checked-in prebuilt
  wrapper normalize the packaged library name to the plain
  `nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
  teaches both the wrapper and the packaged runner source to infer
  `RUSTUP_HOME` from `rustup show home` when the environment does not
  already provide it.
  
  After the prebuilt Windows lint job started running successfully, it
  also surfaced a handful of existing anonymous literal callsites in
  `windows-sandbox-rs`. This PR now annotates those callsites so the new
  cross-platform lint job is green on the current tree.
  
  ## What Changed
  - checked in the current
  `tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
  - kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
  for lint development
  - added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
  normal enforcement path, using the checked-in DotSlash package and
  bundled `cargo-dylint`
  - updated `just clippy` and `just argument-comment-lint` to use the
  prebuilt wrapper
  - split `.github/workflows/rust-ci.yml` so source-package checks live in
  a dedicated `argument_comment_lint_package` job, while the released lint
  runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
  Windows
  - kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
  CI matrix, since the prebuilt package still relies on rustup-provided
  toolchain components
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
  normalize host-qualified nightly library filenames, keep the `rustup`
  shim directory ahead of direct toolchain `cargo` binaries, and export
  `RUSTUP_HOME` when needed for Windows Dylint driver setup
  - updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
  so future published DotSlash artifacts apply the same nightly-filename
  normalization and `RUSTUP_HOME` inference internally
  - fixed the remaining Windows lint violations in
  `codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
  comments at the reported callsites
  - documented the checked-in DotSlash file, wrapper split, archive
  layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
  `tools/argument-comment-lint/README.md`

  Michael Bolin · 2026-03-20 03:19:22 +00:00
  fa2a2f0be9
• V8 Bazel Build (#15021)

  Alternative approach, we use rusty_v8 for all platforms that its
  predefined, but lets build from source a musl v8 version with bazel for
  x86 and aarch64 only. We would need to release this on github and then
  use the release.

  Channing Conger · 2026-03-19 18:05:23 -07:00
  ded7854f09
• Add exec-server exec RPC implementation (#15090)

  Stacked PR 2/3, based on the stub PR.
  
  Adds the exec RPC implementation and process/event flow in exec-server
  only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-03-19 19:00:36 +00:00
  1d210f639e
• Publish runnable DotSlash package for argument-comment lint (#15198)

  ## Why
  
  To date, the argument-comment linter introduced in
  https://github.com/openai/codex/pull/14651 had to be built from source
  to run, which can be a bit slow (both for local dev and when it is run
  in CI). Because of the potential slowness, I did not wire it up to run
  as part of `just clippy` or anything like that. As a result, I have seen
  a number of occasions where folks put up PRs that violate the lint, see
  it fail in CI, and then have to put up their PR again.
  
  The goal of this PR is to pre-build a runnable version of the linter and
  then make it available via a DotSlash file. Once it is available, I will
  update `just clippy` and other touchpoints to make it a natural part of
  the dev cycle so lint violations should get flagged _before_ putting up
  a PR for review.
  
  To get things started, we will build the DotSlash file as part of an
  alpha release. Though I don't expect the linter to change often, so I'll
  probably change this to only build as part of mainline releases once we
  have a working DotSlash file. (Ultimately, we should probably move the
  linter into its own repo so it can have its own release cycle.)
  
  ## What Changed
  - add a reusable `rust-release-argument-comment-lint.yml` workflow that
  builds host-specific archives for macOS arm64, Linux arm64/x64, and
  Windows x64
  - wire `rust-release.yml` to publish the `argument-comment-lint`
  DotSlash manifest on all releases for now, including alpha tags
  - package a runnable layout instead of a bare library
  
  The Unix archive layout is:
  
  ```text
  argument-comment-lint/
    bin/
      argument-comment-lint
      cargo-dylint
    lib/
      libargument_comment_lint@nightly-2025-09-18-<target>.dylib|so
  ```
  
  On Windows the same layout is published as a `.zip`, with `.exe` and
  `.dll` filenames instead.
  
  DotSlash resolves the package entrypoint to
  `argument-comment-lint/bin/argument-comment-lint`. That runner finds the
  sibling bundled `cargo-dylint` binary plus the single packaged Dylint
  library under `lib/`, then invokes `cargo-dylint dylint --lib-path
  <that-library>` with the repo's default lint settings.

  Michael Bolin · 2026-03-19 18:59:02 +00:00
  b87ba0a3cc
• fix: try to fix "Stage npm package" step in ci.yml (#15092)

  Fix the CI job by updating it to use artifacts from a more recent
  release (`0.115.0`) instead of the existing one (`0.74.0`).
  
  This step in our CI job on PRs started failing today:
  
  
  https://github.com/openai/codex/blob/334164a6f714c171bb9f6440c7d3cd04ec04d295/.github/workflows/ci.yml#L33-L47
  
  I believe it's because this test verifies that the "package npm" script
  works, but we want it to be fast and not wait for binaries to be built,
  so it uses a GitHub workflow that's already done. Because it was using a
  GitHub workflow associated with `0.74.0`, it seems likely that
  workflow's history has been reaped, so we need to use a newer one.

  Michael Bolin · 2026-03-18 13:52:33 -07:00
  392347d436
• Pin setup-zig GitHub Action to immutable SHA (#14858)

  ### Motivation
  - Pinning the action to an immutable commit SHA reduces the risk of
  arbitrary code execution in runners with repository access and secrets.
  
  ### Description
  - Replaced `uses: mlugg/setup-zig@v2` with `uses:
  mlugg/setup-zig@d1434d0886 # v2` in three
  workflow files.
  - Updated the following files: ` .github/workflows/rust-ci.yml`, `
  .github/workflows/rust-release.yml`, and `
  .github/workflows/shell-tool-mcp.yml` to reference the immutable SHA
  while preserving the original `v2` intent in a trailing comment.
  
  ### Testing
  - No automated tests were run because this is a workflow-only change and
  does not affect repository source code, so CI validation will occur on
  the next workflow execution.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69763f570234832d9c67b1b66a27c78d)

  viyatb-oai · 2026-03-17 22:40:14 -07:00
  a3613035f3
• fix: tighten up shell arg quoting in GitHub workflows (#14864)

  Inspired by the work done over in
  https://github.com/openai/codex-action/pull/74, this tightens up our use
  of GitHub expressions as shell/environment variables.

  Michael Bolin · 2026-03-16 22:01:16 -07:00
  15ede607a0
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• check for large binaries in CI (#14382)

  Prevent binaries >500KB from being committed. And maintain an allowlist
  if we need to bypass on a case-by-case basis.
  
  I checked the currently tracked binary-like assets in the repo. There
  are only 5 obvious committed binaries by extension/MIME type:
  - `.github/codex-cli-splash.png`: `838,131` bytes, about `818 KiB`
  - `codex-rs/vendor/bubblewrap/bubblewrap.jpg`: `40,239` bytes, about `39
  KiB`
  -
  `codex-rs/skills/src/assets/samples/skill-creator/assets/skill-creator.png`:
  `1,563` bytes
  - `codex-rs/skills/src/assets/samples/openai-docs/assets/openai.png`:
  `1,429` bytes
  -
  `codex-rs/skills/src/assets/samples/skill-installer/assets/skill-installer.png`:
  `1,086` bytes
  
  So `500 KB` looks like a good default for this repo. It would only trip
  on one existing intentional asset, which keeps the allowlist small and
  the policy easy to understand.
  
  Here's a smoke-test from a throwaway branch that tries to commit a large
  binary:
  https://github.com/openai/codex/actions/runs/22971558828/job/66689330435?pr=14383

  Owen Lin · 2026-03-11 22:39:08 +00:00
  f50e88db82
• Increase sdk workflow timeout to 15 minutes (#14252)

  - raise the sdk workflow job timeout from 10 to 15 minutes to reduce
  false cancellations near the current limit
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-11 12:33:08 -07:00
  b1dddcb76e
• Codex/winget auto update (#12943)

  Publish CLI releases to winget.
  
  Uses https://github.com/vedantmgoyal9/winget-releaser to greatly reduce
  boilerplate needed to create winget-pkgs manifets

  iceweasel-oai · 2026-03-06 14:04:30 -08:00
  8ede18011a
• chore(deps): bump actions/upload-artifact from 6 to 7 (#13207)

  Bumps
  [actions/upload-artifact](https://github.com/actions/upload-artifact)
  from 6 to 7.
  <details>
  <summary>Release notes</summary>
  <p><em>Sourced from <a
  href="https://github.com/actions/upload-artifact/releases">actions/upload-artifact's
  releases</a>.</em></p>
  <blockquote>
  <h2>v7.0.0</h2>
  <h2>v7 What's new</h2>
  <h3>Direct Uploads</h3>
  <p>Adds support for uploading single files directly (unzipped). Callers
  can set the new <code>archive</code> parameter to <code>false</code> to
  skip zipping the file during upload. Right now, we only support single
  files. The action will fail if the glob passed resolves to multiple
  files. The <code>name</code> parameter is also ignored with this
  setting. Instead, the name of the artifact will be the name of the
  uploaded file.</p>
  <h3>ESM</h3>
  <p>To support new versions of the <code>@actions/*</code> packages,
  we've upgraded the package to ESM.</p>
  <h2>What's Changed</h2>
  <ul>
  <li>Add proxy integration test by <a
  href="https://github.com/Link"><code>@​Link</code></a>- in <a
  href="https://redirect.github.com/actions/upload-artifact/pull/754">actions/upload-artifact#754</a></li>
  <li>Upgrade the module to ESM and bump dependencies by <a
  href="https://github.com/danwkennedy"><code>@​danwkennedy</code></a> in
  <a
  href="https://redirect.github.com/actions/upload-artifact/pull/762">actions/upload-artifact#762</a></li>
  <li>Support direct file uploads by <a
  href="https://github.com/danwkennedy"><code>@​danwkennedy</code></a> in
  <a
  href="https://redirect.github.com/actions/upload-artifact/pull/764">actions/upload-artifact#764</a></li>
  </ul>
  <h2>New Contributors</h2>
  <ul>
  <li><a href="https://github.com/Link"><code>@​Link</code></a>- made
  their first contribution in <a
  href="https://redirect.github.com/actions/upload-artifact/pull/754">actions/upload-artifact#754</a></li>
  </ul>
  <p><strong>Full Changelog</strong>: <a
  href="https://github.com/actions/upload-artifact/compare/v6...v7.0.0">https://github.com/actions/upload-artifact/compare/v6...v7.0.0</a></p>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/actions/upload-artifact/commit/bbbca2ddaa5d8feaa63e36b76fdaad77386f024f"><code>bbbca2d</code></a>
  Support direct file uploads (<a
  href="https://redirect.github.com/actions/upload-artifact/issues/764">#764</a>)</li>
  <li><a
  href="https://github.com/actions/upload-artifact/commit/589182c5a4cec8920b8c1bce3e2fab1c97a02296"><code>589182c</code></a>
  Upgrade the module to ESM and bump dependencies (<a
  href="https://redirect.github.com/actions/upload-artifact/issues/762">#762</a>)</li>
  <li><a
  href="https://github.com/actions/upload-artifact/commit/47309c993abb98030a35d55ef7ff34b7fa1074b5"><code>47309c9</code></a>
  Merge pull request <a
  href="https://redirect.github.com/actions/upload-artifact/issues/754">#754</a>
  from actions/Link-/add-proxy-integration-tests</li>
  <li><a
  href="https://github.com/actions/upload-artifact/commit/02a8460834e70dab0ce194c64360c59dc1475ef0"><code>02a8460</code></a>
  Add proxy integration test</li>
  <li>See full diff in <a
  href="https://github.com/actions/upload-artifact/compare/v6...v7">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/upload-artifact&package-manager=github_actions&previous-version=6&new-version=7)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Co-authored-by: Eric Traut <etraut@openai.com>

  dependabot[bot] · 2026-03-04 18:32:35 -07:00
  be5e8fbd37
• chore(deps): bump actions/download-artifact from 7 to 8 (#13208)

  Bumps
  [actions/download-artifact](https://github.com/actions/download-artifact)
  from 7 to 8.
  <details>
  <summary>Release notes</summary>
  <p><em>Sourced from <a
  href="https://github.com/actions/download-artifact/releases">actions/download-artifact's
  releases</a>.</em></p>
  <blockquote>
  <h2>v8.0.0</h2>
  <h2>v8 - What's new</h2>
  <h3>Direct downloads</h3>
  <p>To support direct uploads in <code>actions/upload-artifact</code>,
  the action will no longer attempt to unzip all downloaded files.
  Instead, the action checks the <code>Content-Type</code> header ahead of
  unzipping and skips non-zipped files. Callers wishing to download a
  zipped file as-is can also set the new <code>skip-decompress</code>
  parameter to <code>false</code>.</p>
  <h3>Enforced checks (breaking)</h3>
  <p>A previous release introduced digest checks on the download. If a
  download hash didn't match the expected hash from the server, the action
  would log a warning. Callers can now configure the behavior on mismatch
  with the <code>digest-mismatch</code> parameter. To be secure by
  default, we are now defaulting the behavior to <code>error</code> which
  will fail the workflow run.</p>
  <h3>ESM</h3>
  <p>To support new versions of the @actions/* packages, we've upgraded
  the package to ESM.</p>
  <h2>What's Changed</h2>
  <ul>
  <li>Don't attempt to un-zip non-zipped downloads by <a
  href="https://github.com/danwkennedy"><code>@​danwkennedy</code></a> in
  <a
  href="https://redirect.github.com/actions/download-artifact/pull/460">actions/download-artifact#460</a></li>
  <li>Add a setting to specify what to do on hash mismatch and default it
  to <code>error</code> by <a
  href="https://github.com/danwkennedy"><code>@​danwkennedy</code></a> in
  <a
  href="https://redirect.github.com/actions/download-artifact/pull/461">actions/download-artifact#461</a></li>
  </ul>
  <p><strong>Full Changelog</strong>: <a
  href="https://github.com/actions/download-artifact/compare/v7...v8.0.0">https://github.com/actions/download-artifact/compare/v7...v8.0.0</a></p>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/actions/download-artifact/commit/70fc10c6e5e1ce46ad2ea6f2b72d43f7d47b13c3"><code>70fc10c</code></a>
  Merge pull request <a
  href="https://redirect.github.com/actions/download-artifact/issues/461">#461</a>
  from actions/danwkennedy/digest-mismatch-behavior</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/f258da9a506b755b84a09a531814700b86ccfc62"><code>f258da9</code></a>
  Add change docs</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/ccc058e5fbb0bb2352213eaec3491e117cbc4a5c"><code>ccc058e</code></a>
  Fix linting issues</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/bd7976ba57ecea96e6f3df575eb922d11a12a9fd"><code>bd7976b</code></a>
  Add a setting to specify what to do on hash mismatch and default it to
  <code>error</code></li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/ac21fcf45e0aaee541c0f7030558bdad38d77d6c"><code>ac21fcf</code></a>
  Merge pull request <a
  href="https://redirect.github.com/actions/download-artifact/issues/460">#460</a>
  from actions/danwkennedy/download-no-unzip</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/15999bff51058bc7c19b50ebbba518eaef7c26c0"><code>15999bf</code></a>
  Add note about package bumps</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/974686ed5098c7f9c9289ec946b9058e496a2561"><code>974686e</code></a>
  Bump the version to <code>v8</code> and add release notes</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/fbe48b1d2756394be4cd4358ed3bc1343b330e75"><code>fbe48b1</code></a>
  Update test names to make it clearer what they do</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/96bf374a614d4360e225874c3efd6893a3f285e7"><code>96bf374</code></a>
  One more test fix</li>
  <li><a
  href="https://github.com/actions/download-artifact/commit/b8c4819ef592cbe04fd93534534b38f853864332"><code>b8c4819</code></a>
  Fix skip decompress test</li>
  <li>Additional commits viewable in <a
  href="https://github.com/actions/download-artifact/compare/v7...v8">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/download-artifact&package-manager=github_actions&previous-version=7&new-version=8)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2026-03-04 17:40:54 -07:00
  84ba9f8e74
• [release] temporarily use thin LTO for releases (#13506)
  Michael Bolin · 2026-03-04 14:10:54 -08:00
  4907096d13
• Require deduplicator success before commenting (#13399)

  Fixed recent regression in issue dedup action

  Eric Traut · 2026-03-03 15:32:47 -07:00
  bab32afa93
• Add Windows direct install script (#12741)

  ## Summary
  - add a direct install script for Windows at
  `scripts/install/install.ps1`
  - extend release staging so `install.ps1` is published alongside
  `install.sh`
  - install the Windows runtime payload (`codex.exe`, `rg.exe`, and helper
  binaries) from the existing platform npm package
  
  ## Dependencies
  - Depends on https://github.com/openai/codex/pull/12740
  
  ## Testing
  - Smoke-tested with powershell

  EFRAZER-oai · 2026-03-03 09:25:50 -08:00
  168e35b6f2
• fix: use https://git.savannah.gnu.org/git/bash instead of https://github.com/bolinfest/bash (#13057)

  Historically, we cloned the Bash repo from
  https://github.com/bminor/bash, but for whatever reason, it was removed
  at some point.
  
  I had a local clone of it, so I pushed it to
  https://github.com/bolinfest/bash so that we could continue running our
  CI job. I did this in https://github.com/openai/codex/pull/9563, and as
  you can see, I did not tamper with the commit hash we used as the basis
  of this build.
  
  Using a personal fork is not great, so this PR changes the CI job to use
  what appears to be considered the source of truth for Bash, which is
  https://git.savannah.gnu.org/git/bash.git.
  
  Though in testing this out, it appears this Git server does not support
  the combination of `git clone --depth 1
  https://git.savannah.gnu.org/git/bash` and `git fetch --depth 1 origin
  a8a1c2fac029404d3f42cd39f5a20f24b6e4fe4b`, as it fails with the
  following error:
  
  ```
  error: Server does not allow request for unadvertised object a8a1c2fac029404d3f42cd39f5a20f24b6e4fe4b
  ```
  
  so unfortunately this means that we have to do a full clone instead of a
  shallow clone in our CI jobs, which will be a bit slower.
  
  Also updated `codex-rs/shell-escalation/README.md` to reflect this
  change.

  Michael Bolin · 2026-03-02 09:09:54 -08:00
  3241c1c6cc
• Fix issue deduplication workflow for Codex issues (#13215)

  Fixes #13203
  
  Summary
  - split the duplicate-finding workflow into two jobs so we gather all
  issues first
  - add an open-issue fallback job that runs only when the full scan finds
  nothing
  - centralize final selection so `comment-on-issue` always sees the best
  dedupe output

  Eric Traut · 2026-03-01 22:45:50 -07:00
  d94f0b6ce7
• fix: disable Bazel builds in CI on ubuntu-24.04-arm until we can stabilize them (#13055)

  The other three Bazel builds have experienced low flakiness in my
  experience whereas I find myself re-running the `ubuntu-24.04-arm` jobs
  often to shake out the flakes. Disabling for now.

  Michael Bolin · 2026-02-27 12:49:13 -08:00
  6e0f1e9469
• Attempt 2 to fix release (#12856)
  pakrym-oai · 2026-02-25 19:12:19 -08:00
  b65205fb3d
• Try fixing windows pipeline (#12848)

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

  pakrym-oai · 2026-02-25 18:18:00 -08:00
  ea621ae152
• Add macOS and Linux direct install script (#12740)

  ## Summary
  - add a direct install script for macOS and Linux at
  `scripts/install/install.sh`
  - stage `install.sh` into `dist/` during release so it is published as a
  GitHub release asset
  - reuse the existing platform npm payload so the installer includes both
  `codex` and `rg`
  
  ## Testing
  - `bash -n scripts/install/install.sh`
  - local macOS `curl | sh` smoke test against a locally served copy of
  the script

  EFRAZER-oai · 2026-02-26 00:33:50 +00:00
  a1cd78c818
• tests(js_repl): stabilize CI runtime test execution (#12407)

  ## Summary
  
  Stabilize `js_repl` runtime test setup in CI and move tool-facing
  `js_repl` behavior coverage into integration tests.
  
  This is a test/CI change only. No production `js_repl` behavior change
  is intended.
  
  ## Why
  
  - Bazel test sandboxes (especially on macOS) could resolve a different
  `node` than the one installed by `actions/setup-node`, which caused
  `js_repl` runtime/version failures.
  - `js_repl` runtime tests depend on platform-specific
  sandbox/test-harness behavior, so they need explicit gating in a
  base-stability commit.
  - Several tests in the `js_repl` unit test module were actually
  black-box/tool-level behavior tests and fit better in the integration
  suite.
  
  ## Changes
  
  - Add `actions/setup-node` to the Bazel and Rust `Tests` workflows,
  using the exact version pinned in the repo’s Node version file.
  - In Bazel (non-Windows), pass `CODEX_JS_REPL_NODE_PATH=$(which node)`
  into test env so `js_repl` uses the `actions/setup-node` runtime inside
  Bazel tests.
  - Add a new integration test suite for `js_repl` tool behavior and
  register it in the core integration test suite module.
  - Move black-box `js_repl` behavior tests into the integration suite
  (persistence/TLA, builtin tool invocation, recursive self-call
  rejection, `process` isolation, blocked builtin imports).
  - Keep white-box manager/kernel tests in the `js_repl` unit test module.
  - Gate `js_repl` runtime tests to run only on macOS and only when a
  usable Node runtime is available (skip on other platforms / missing Node
  in this commit).
  
  ## Impact
  
  - Reduces `js_repl` CI failures caused by Node resolution drift in
  Bazel.
  - Improves test organization by separating tool-facing behavior tests
  from white-box manager/kernel tests.
  - Keeps the base commit stable while expanding `js_repl` runtime
  coverage.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - ✅ `1` https://github.com/openai/codex/pull/12372
  - 👉 `2` https://github.com/openai/codex/pull/12407
  - ⏳ `3` https://github.com/openai/codex/pull/12185
  - ⏳ `4` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-24 21:04:34 -08:00
  8f3f2c3c02
• add AWS_LC_SYS_NO_JITTER_ENTROPY=1 to release musl build step to unblock releases (#12720)

  linux musl build steps in `rust-release.yml` are [currently
  broken](https://github.com/openai/codex/actions/runs/22367312571)
  because of linking issues due to ubsan-calling types (`jitterentropy`)
  leaking into the build.
  
  add `AWS_LC_SYS_NO_JITTER_ENTROPY=1` to the musl build step to avoid
  linking those ubsan-calling types. this is a more temporary fix, we need
  to clean up ubsan usage upstream so they dont leak into release-build
  steps anyways.
  
  codex's more thorough explanation below:
  
  [pr 9859](https://github.com/openai/codex/pull/9859) added [MITM
  init](https://github.com/openai/codex/pull/9859/changes#diff-db782967007060c5520651633e1ea21681d64be21f2b791d3d84519860245b97R62-R68)
  in network-proxy, which wires in cert generation code (rcgen/rustls).
  this didnt bump/change dep versions, but it changed symbol reachability
  at link time.
  
  for musl builds, that made aws-lc-sys’s jitterentropy objects get pulled
  into the final link. those objects contain UBSan calls
  (__ubsan_handle_*). musl release linking is static (*-linux-musl-gcc,
  -nodefaultlibs) and does not link a musl UBSan runtime, so link fails
  with undefined __ubsan_*.
  
  before, our custom musl CI UBSan steps (install libubsan1, RUSTC_WRAPPER
  + LD_PRELOAD, partial flag scrubbing) masked some sanitizer issues.
  after this pr, more aws-lc code became link-reachable, and that band-aid
  wasn't enough.

  sayan-oai · 2026-02-24 18:11:04 -08:00
  74e112ea09
• refactor: delete exec-server and move execve wrapper into shell-escalation (#12632)

  ## Why
  
  We already plan to remove the shell-tool MCP path, and doing that
  cleanup first makes the follow-on `shell-escalation` work much simpler.
  
  This change removes the last remaining reason to keep
  `codex-rs/exec-server` around by moving the `codex-execve-wrapper`
  binary and shared shell test fixtures to the crates/tests that now own
  that functionality.
  
  ## What Changed
  
  ### Delete `codex-rs/exec-server`
  
  - Remove the `exec-server` crate, including the MCP server binary,
  MCP-specific modules, and its test support/test suite
  - Remove `exec-server` from the `codex-rs` workspace and update
  `Cargo.lock`
  
  ### Move `codex-execve-wrapper` into `codex-rs/shell-escalation`
  
  - Move the wrapper implementation into `shell-escalation`
  (`src/unix/execve_wrapper.rs`)
  - Add the `codex-execve-wrapper` binary entrypoint under
  `shell-escalation/src/bin/`
  - Update `shell-escalation` exports/module layout so the wrapper
  entrypoint is hosted there
  - Move the wrapper README content from `exec-server` to
  `shell-escalation/README.md`
  
  ### Move shared shell test fixtures to `app-server`
  
  - Move the DotSlash `bash`/`zsh` test fixtures from
  `exec-server/tests/suite/` to `app-server/tests/suite/`
  - Update `app-server` zsh-fork tests to reference the new fixture paths
  
  ### Keep `shell-tool-mcp` as a shell-assets package
  
  - Update `.github/workflows/shell-tool-mcp.yml` packaging so the npm
  artifact contains only patched Bash/Zsh payloads (no Rust binaries)
  - Update `shell-tool-mcp/package.json`, `shell-tool-mcp/src/index.ts`,
  and docs to reflect the shell-assets-only package shape
  - `shell-tool-mcp-ci.yml` does not need changes because it is already
  JS-only
  
  ## Verification
  
  - `cargo shear`
  - `cargo clippy -p codex-shell-escalation --tests`
  - `just clippy`

  Michael Bolin · 2026-02-23 20:10:22 -08:00
  38f84b6b29
• chore: better bazel test logs (#12576)

  ## Summary
  
  Improve Bazel CI failure diagnostics by printing the tail of each failed
  target’s test.log directly in the GitHub Actions output.
  
  Today, when a large Bazel test target fails (for example tests of
  `codex-core`), the workflow often only shows a target-level Exit 101
  plus a path to Bazel’s test.log. That makes it hard to see the actual
  failing Rust test and panic without digging into artifacts or
  reproducing locally.
  
  This change makes the workflow automatically surface that information
  inline.
  
    ## What Changed
  
  In .github/workflows/bazel.yml:
  
    - Capture Bazel console output via tee
    - Preserve the Bazel exit code when piping (PIPESTATUS[0])
    - On failure:
        - Parse failed Bazel test targets from FAIL: //... lines
        - Resolve Bazel test log directory via bazel info bazel-testlogs
        - Print tail -n 200 for each failed target’s test.log
        - Group each target’s output in GitHub Actions logs (::group::)
  
  ## Bonus
  Disable `experimental_remote_repo_contents_cache` to prevent "Permission
  Denied"

  jif-oai · 2026-02-23 08:13:29 -08:00
  3b6c50d925
• ci(bazel): install Node from node-version.txt in remote image (#12205)

  ## Summary
  Install Node in the Bazel remote execution image using the version
  pinned in `codex-rs/node-version.txt`.
  
  ## Why
  `js_repl` tests run under Bazel remote execution and require a modern
  Node runtime. Runner-level `setup-node` does not guarantee Node is
  available (or recent enough) inside the remote worker container.
  
  ## What changed
  - Updated `.github/workflows/Dockerfile.bazel` to install Node from
  official tarballs at image build time.
  - Added `xz-utils` for extracting `.tar.xz` archives.
  - Copied `codex-rs/node-version.txt` into the image build context and
  used it as the single source of truth for Node version.
  - Added architecture mapping for multi-arch builds:
    - `amd64 -> x64`
    - `arm64 -> arm64`
  - Verified install during image build with:
    - `node --version`
    - `npm --version`
  
  ## Impact
  - Bazel remote workers should now have the required Node version
  available for `js_repl` tests.
  - Keeps Node version synchronized with repo policy via
  `codex-rs/node-version.txt`.
  
  ## Testing
  - Verified Dockerfile changes and build steps locally (build-time
  commands are deterministic and fail fast on unsupported arch/version
  fetch issues).
  
  ## Follow-up
  - Rebuild and publish the Bazel runner image for both `linux/amd64` and
  `linux/arm64`.
  - Update image digests in `rbe.bzl` to roll out this runtime update in
  CI.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - ✅ `1` https://github.com/openai/codex/pull/12300
  - ✅ `2` https://github.com/openai/codex/pull/12275
  - 👉 `3` https://github.com/openai/codex/pull/12205
  - ⏳ `4` https://github.com/openai/codex/pull/12185
  - ⏳ `5` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-20 11:51:17 -08:00
  67e802e26b
• fix(linux-sandbox): mount /dev in bwrap sandbox (#12081)

  ## Summary
  - Updates the Linux bubblewrap sandbox args to mount a minimal `/dev`
  using `--dev /dev` instead of only binding `/dev/null`. tools needing
  entropy (git, crypto libs, etc.) can fail.
  
  - Changed mount order so `--dev /dev` is added before writable-root
  `--bind` mounts, preserving writable `/dev/*` submounts like `/dev/shm`
  
  ## Why
  Fixes sandboxed command failures when reading `/dev/urandom` (and
  similar standard device-node access).
  
  
  Fixes https://github.com/openai/codex/issues/12056

  viyatb-oai · 2026-02-18 23:27:32 -08:00
  4fe99b086f
• Updated issue labeler script to include safety-check label (#12096)

  Also deleted obsolete prompt file

  Eric Traut · 2026-02-17 22:44:42 -08:00
  57f4e37539
• don't fail if an npm publish attempt is for an existing version. (#12044)
  iceweasel-oai · 2026-02-17 14:20:29 -08:00
  c4bb7db159
• fix(ci) Fix shell-tool-mcp.yml (#11969)

  ## Summary
  We're seeing failures for shell-tool-mcp.yml during git checkouts. This
  is a quick attempt to unblock releases - we should revisit this build
  pipeline since we've hit a number of errors.

  Dylan Hurd · 2026-02-17 11:13:18 +00:00
  fcf16e97a6
• bazel: enforce MODULE.bazel.lock sync with Cargo.lock (#11790)

  ## Why this change
  
  When Cargo dependencies change, it is easy to end up with an unexpected
  local diff in
  `MODULE.bazel.lock` after running Bazel. That creates noisy working
  copies and pushes lockfile fixes
  later in the cycle. This change addresses that pain point directly.
  
  ## What this change enforces
  
  The expected invariant is: after dependency updates, `MODULE.bazel.lock`
  is already in sync with
  Cargo resolution. In practice, running `bazel mod deps` should not
  mutate the lockfile in a clean
  state. If it does, the dependency update is incomplete.
  
  ## How this is enforced
  
  This change adds a single lockfile check script that snapshots
  `MODULE.bazel.lock`, runs
  `bazel mod deps`, and fails if the file changes. The same check is wired
  into local workflow
  commands (`just bazel-lock-update` and `just bazel-lock-check`) and into
  Bazel CI (Linux x86_64 job)
  so drift is caught early and consistently. The developer documentation
  is updated in
  `codex-rs/docs/bazel.md` and `AGENTS.md` to make the expected flow
  explicit.
  
  `MODULE.bazel.lock` is also refreshed in this PR to match the current
  Cargo dependency resolution.
  
  ## Expected developer workflow
  
  After changing `Cargo.toml` or `Cargo.lock`, run `just
  bazel-lock-update`, then run
  `just bazel-lock-check`, and include any resulting `MODULE.bazel.lock`
  update in the same change.
  
  ## Testing
  
  Ran `just bazel-lock-check` locally.

  Josh McKinney · 2026-02-14 02:11:19 +00:00
  de93cef5b7
• Improve GitHub issue deduplication reliability by introducing a stage… (#11769)

  …d two-pass Codex search strategy with deterministic fallback behavior,
  and remove an obsolete prompt file that was no longer used.
  
  ### Changes
  - Updated `workflows/issue-deduplicator.yml`:
  - Added richer issue input fields (`state`, `updatedAt`, `labels`) for
  model context.
    - Added two candidate pools:
      - `codex-existing-issues-all.json` (`--state all`)
      - `codex-existing-issues-open.json` (`--state open`)
  - Added body truncation during JSON preparation to reduce prompt noise.
    - Added **Pass 1** Codex run over all issues.
    - Added normalization/validation step for Pass 1 output:
      - tolerant JSON parsing
      - self-issue filtering
      - deduplication
      - cap to 5 results
  - Added **Pass 2 fallback** Codex run over open issues only, triggered
  only when Pass 1 has no usable matches.
  - Added normalization/validation step for Pass 2 output (same
  filtering/dedup/cap behavior).
    - Added final deterministic selector:
      - prefer pass 2 if it finds matches
      - otherwise use pass 1
      - otherwise return no matches
    - Added observability logs:
      - pool sizes
      - per-pass parse/match status
      - final pass selected and final duplicate count
    - Kept public issue-comment format unchanged.
  - Added comment documenting that prompt text now lives inline in
  workflow.
  
  - Deleted obsolete file:
    - `/prompts/issue-deduplicator.txt`
  
  ### Behavior Impact
  - Better duplicate recall when broad search fails by retrying against
  active issues only.
  - More deterministic/noise-resistant output handling.
  - No change to workflow trigger conditions, permissions, or issue
  comment structure.

  Eric Traut · 2026-02-13 12:01:07 -08:00
  ffef5ce5de
• fix(shell-tool-mcp) build dependencies (#11709)

  ## Summary
  Based on our most recent [release
  attempt](https://github.com/openai/codex/actions/runs/21980518940/job/63501739210)
  we are not building the shell-tool-mcp job correctly. This one is
  outside my expertise, but seems mostly reasonable.
  
  ## Testing
   - [x] We really need dry runs of these

  Dylan Hurd · 2026-02-13 09:30:37 +00:00
  e6eb6be683
• fix(ci) lock rust toolchain at 1.93.0 to unblock (#11703)

  ## Summary
  CI is broken on main because our CI toolchain is trying to run 1.93.1
  while our rust toolchain is locked at 1.93.0. I'm sure it's likely safe
  to upgrade, but let's keep things stable for now.
  
  ## Testing
  - [x] CI should hopefully pass

  Dylan Hurd · 2026-02-13 08:44:23 +00:00
  fca5629e34
• feat(shell-tool-mcp): add patched zsh build pipeline (#11668)

  ## Summary
  - add `shell-tool-mcp/patches/zsh-exec-wrapper.patch` against upstream
  zsh `77045ef899e53b9598bebc5a41db93a548a40ca6`
  - add `zsh-linux` and `zsh-darwin` jobs to
  `.github/workflows/shell-tool-mcp.yml`
  - stage zsh binaries under `artifacts/vendor/<target>/zsh/<variant>/zsh`
  - include zsh artifact jobs in `package.needs`
  - mark staged zsh binaries executable during packaging
  
  ## Notes
  - zsh source is cloned from `https://git.code.sf.net/p/zsh/code`
  - workflow pins zsh commit `77045ef899e53b9598bebc5a41db93a548a40ca6`
  - zsh build runs `./Util/preconfig` before `./configure`
  
  ## Validation
  - parsed workflow YAML locally (`yaml-ok`)
  - validated zsh patch applies cleanly with `git apply --check` on a
  fresh zsh clone

  Jeremy Rose · 2026-02-13 01:34:48 +00:00
  9cf7a07281
• rust-release: exclude cargo-timing.html from release assets (#11564)

  ## Why
  The `release` job in `.github/workflows/rust-release.yml` uploads
  `files: dist/**` via `softprops/action-gh-release`. The downloaded
  timing artifacts include multiple files with the same basename,
  `cargo-timing.html` (one per target), which causes release asset
  collisions/races and can fail with GitHub release-assets API `404 Not
  Found` errors.
  
  ## What Changed
  - Updated the existing cleanup step before `Create GitHub Release` to
  remove all `cargo-timing.html` files from `dist/`.
  - Removed any now-empty directories after deleting those timing files.
  
  Relevant change:
  -
  https://github.com/openai/codex/blob/daba003d32f299579e9b89240aa8ebdc9f161424/.github/workflows/rust-release.yml#L423
  
  ## Verification
  - Confirmed from failing release logs that multiple `cargo-timing.html`
  files were being included in `dist/**` and that the release step failed
  while operating on duplicate-named assets.
  - Verified the workflow now deletes those files before the release
  upload step, so `cargo-timing.html` is no longer part of the release
  asset set.

  Michael Bolin · 2026-02-12 00:56:47 -08:00
  26d9bddc52
• Fix linux-musl release link failures caused by glibc-only libcap artifacts (#11556)

  Problem:
  The `aarch64-unknown-linux-musl` release build was failing at link time
  with
  `/usr/bin/ld: cannot find -lcap` while building binaries that
  transitively pull
  in `codex-linux-sandbox`.
  
  Why this is the right fix:
  `codex-linux-sandbox` compiles vendored bubblewrap and links `libcap`.
  In the
  musl jobs, we were installing distro `libcap-dev`, which provides
  host/glibc
  artifacts. That is not a valid source of target-compatible static libcap
  for
  musl cross-linking, so the fix is to produce a target-compatible libcap
  inside
  the musl tool bootstrap and point pkg-config at it.
  
  This also closes the CI coverage gap that allowed this to slip through:
  the
  `rust-ci.yml` matrix did not exercise `aarch64-unknown-linux-musl` in
  `release`
  mode. Adding that target/profile combination to CI is the right
  regression
  barrier for this class of failure.
  
  What changed:
  - Updated `.github/scripts/install-musl-build-tools.sh` to install
  tooling
    needed to fetch/build libcap sources (`curl`, `xz-utils`, certs).
  - Added deterministic libcap bootstrap in the musl tool root:
    - download `libcap-2.75` from kernel.org
    - verify SHA256
    - build with the target musl compiler (`*-linux-musl-gcc`)
    - stage `libcap.a` and headers under the target tool root
    - generate a target-scoped `libcap.pc`
  - Exported target `PKG_CONFIG_PATH` so builds resolve the staged musl
  libcap
    instead of host pkg-config/lib paths.
  - Updated `.github/workflows/rust-ci.yml` to add a `release` matrix
  entry for
    `aarch64-unknown-linux-musl` on the ARM runner.
  - Updated `.github/workflows/rust-ci.yml` to set
  `CARGO_PROFILE_RELEASE_LTO=thin` for `release` matrix entries (and keep
  `fat`
  for non-release entries), matching the release-build tradeoff already
  used in
    `rust-release.yml` while reducing CI runtime.
  
  Verification:
  - Reproduced the original failure in CI-like containers:
    - `aarch64-unknown-linux-musl` failed with `cannot find -lcap`.
  - Verified the underlying mismatch by forcing host libcap into the link:
    - link then failed with glibc-specific unresolved symbols
      (`__isoc23_*`, `__*_chk`), confirming host libcap was unsuitable.
  - Verified the fix in CI-like containers after this change:
  - `cargo build -p codex-linux-sandbox --target
  aarch64-unknown-linux-musl --release` -> pass
  - `cargo build -p codex-linux-sandbox --target x86_64-unknown-linux-musl
  --release` -> pass
  - Triggered `rust-ci` on this branch and confirmed the new job appears:
  - `Lint/Build — ubuntu-24.04-arm - aarch64-unknown-linux-musl (release)`

  Michael Bolin · 2026-02-12 08:08:32 +00:00
  08a000866f
• ci: capture cargo timings in Rust CI and release workflows (#11543)

  ## Why
  We want actionable build-hotspot data from CI so we can tune Rust
  workflow performance (for example, target coverage, cache behavior, and
  job shape) based on actual compile-time bottlenecks.
  
  `cargo` timing reports are lightweight and provide a direct way to
  inspect where compilation time is spent.
  
  ## What Changed
  - Updated `.github/workflows/rust-release.yml` to run `cargo build` with
  `--timings` and upload `target/**/cargo-timings/cargo-timing.html`.
  - Updated `.github/workflows/rust-release-windows.yml` to run `cargo
  build` with `--timings` and upload
  `target/**/cargo-timings/cargo-timing.html`.
  - Updated `.github/workflows/rust-ci.yml` to:
    - run `cargo clippy` with `--timings`
    - run `cargo nextest run` with `--timings` (stable-compatible)
  - upload `target/**/cargo-timings/cargo-timing.html` artifacts for both
  the clippy and nextest jobs
  
  Artifacts are matrix-scoped via artifact names so timings can be
  compared per target/profile.
  
  ## Verification
  - Confirmed the net diff is limited to:
    - `.github/workflows/rust-ci.yml`
    - `.github/workflows/rust-release.yml`
    - `.github/workflows/rust-release-windows.yml`
  - Verified timing uploads are added immediately after the corresponding
  timed commands in each workflow.
  - Confirmed stable Cargo accepts plain `--timings` for the compile phase
  (`cargo test --no-run --timings`) and generates
  `target/cargo-timings/cargo-timing.html`.
  - Ran VS Code diagnostics on modified workflow files; no new diagnostics
  were introduced by these changes.

  Michael Bolin · 2026-02-12 05:54:48 +00:00
  2aa8a2e11f
• 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
• ci(windows): use DotSlash for zstd in rust-release-windows (#11542)

  ## Why
  Installing `zstd` via Chocolatey in
  `.github/workflows/rust-release-windows.yml` has been taking about a
  minute on Windows release runs. This adds avoidable latency to each
  release job.
  
  Using DotSlash removes that package-manager install step and pins the
  exact binary we use for compression.
  
  ## What Changed
  - Added `.github/workflows/zstd`, a DotSlash wrapper that fetches
  `zstd-v1.5.7-win64.zip` with pinned size and digest.
  - Updated `.github/workflows/rust-release-windows.yml` to:
    - install DotSlash via `facebook/install-dotslash@v2`
  - replace `zstd -T0 -19 ...` with
  `${GITHUB_WORKSPACE}/.github/workflows/zstd -T0 -19 ...`
  - `windows-aarch64` uses the same win64 upstream zstd artifact because
  upstream releases currently publish `win32` and `win64` binaries.
  
  ## Verification
  - Verified the workflow now resolves the DotSlash file from
  `${GITHUB_WORKSPACE}` while the job runs with `working-directory:
  codex-rs`.
  - Ran VS Code diagnostics on changed files:
    - `.github/workflows/rust-release-windows.yml`
    - `.github/workflows/zstd`

  Michael Bolin · 2026-02-11 20:57:11 -08:00
  c40c508d4e
• ci: remove actions/cache from rust release workflows (#11540)

  ## Why
  
  `rust-release` cache restore has had very low practical value, while
  cache save consistently costs significant time (usually adding ~3
  minutes to the critical path of a release workflow).
  
  From successful release-tag runs with cache steps (`289` runs total):
  - Alpha tags: cache download averaged ~5s/run, cache upload averaged
  ~230s/run.
  - Stable tags: cache download averaged ~5s/run, cache upload averaged
  ~227s/run.
  - Windows release builds specifically: download ~2s/run vs upload
  ~169-170s/run.
  
  Hard step-level signal from the same successful release-tag runs:
  - Cache restore (`Run actions/cache`): `2,314` steps, total `1,515s`
  (~0.65s/step).
  - `95.3%` of restore steps finished in `<=1s`; `99.7%` finished in
  `<=2s`; `0` steps took `>=10s`.
  - Cache save (`Post Run actions/cache`): `2,314` steps, total `66,295s`
  (~28.65s/step).
  
  Run-level framing:
  - Download total was `<=10s` in `288/289` runs (`99.7%`).
  - Upload total was `>=120s` in `285/289` runs (`98.6%`).
  
  The net effect is that release jobs are spending time uploading caches
  that are rarely useful for subsequent runs.
  
  ## What Changed
  
  - Removed the `actions/cache@v5` step from
  `.github/workflows/rust-release.yml`.
  - Removed the `actions/cache@v5` step from
  `.github/workflows/rust-release-windows.yml`.
  - Left build, signing, packaging, and publishing flow unchanged.
  
  ## Validation
  
  - Queried historical `rust-release` run/job step timing and compared
  cache download vs upload for alpha and stable release tags.
  - Spot-checked release logs and observed repeated `Cache not found ...`
  followed by `Cache saved ...` patterns.

  Michael Bolin · 2026-02-11 20:49:26 -08:00
  fffc92a779
• fix: add --test_verbose_timeout_warnings to bazel.yml (#11522)

  This is in response to seeing this on BuildBuddy:
  
  > There were tests whose specified size is too big. Use the
  --test_verbose_timeout_warnings command line option to see which ones
  these are.

  Michael Bolin · 2026-02-11 17:52:06 -08:00
  9722567a80
• feat: try to fix bugs I saw in the wild in the resource parsing logic (#11513)

  I gave Codex the following bug report about the logic to report the
  host's resources introduced in
  https://github.com/openai/codex/pull/11488 and this PR is its proposed
  fix.
  
  The fix seems like an escaping issue, mostly.
  
  ---
  
  The logic to print out the runner specs has an awk error on Mac:
  
  ```
  Runner: GitHub Actions 1014936475
  OS: macOS 15.7.3
  Hardware model: VirtualMac2,1
  CPU architecture: arm64
  Logical CPUs: 5
  Physical CPUs: 5
  awk: syntax error at source line 1
   context is
  	{printf >>>  \ <<< "%.1f GiB\\n\", $1 / 1024 / 1024 / 1024}
  awk: illegal statement at source line 1
  Total RAM: 
  Disk usage:
  Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
  /dev/disk3s5   320Gi   237Gi    64Gi    79%    2.0M  671M    0%   /System/Volumes/Data
  ```
  
  as well as Linux:
  
  ```
  Runner: GitHub Actions 1014936469
  OS: Linux runnervmwffz4 6.11.0-1018-azure #18~24.04.1-Ubuntu SMP Sat Jun 28 04:46:03 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
  awk: cmd. line:1: /Model name/ {gsub(/^[ \t]+/,\"\",$2); print $2; exit}
  awk: cmd. line:1:                              ^ backslash not last character on line
  CPU model: 
  Logical CPUs: 4
  awk: cmd. line:1: /MemTotal/ {printf \"%.1f GiB\\n\", $2 / 1024 / 1024}
  awk: cmd. line:1:                    ^ backslash not last character on line
  Total RAM: 
  Disk usage:
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/root        72G   50G   22G  70% /
  ```

  Michael Bolin · 2026-02-11 16:50:46 -08:00
  fd1efb86df
• feat: build windows support binaries in parallel (#11500)

  Windows release builds were compiling and linking four release binaries
  on a single runner, which slowed the release pipeline. The
  Windows-specific logic also made `rust-release.yml` harder to read and
  maintain.
  
  ## What Changed
  
  - Extracted Windows release logic into a reusable workflow at
  `.github/workflows/rust-release-windows.yml`.
  - Updated `.github/workflows/rust-release.yml` to call the reusable
  Windows workflow via `workflow_call`.
  - Parallelized Windows binary builds with one 4-entry matrix over two
  targets (`x86_64-pc-windows-msvc`, `aarch64-pc-windows-msvc`) and two
  bundles (`primary`, `helpers`).
  - Kept signing centralized per target by downloading both prebuilt
  bundles and signing all four executables together.
  - Preserved final release artifact behavior and filtered intermediate
  `windows-binaries*` artifacts out of the published release asset set.

  Michael Bolin · 2026-02-11 14:58:28 -08:00
  ad9a540ab0
• feat: use more powerful machines for building Windows releases (#11488)

  Windows release builds in `.github/workflows/rust-release.yml` were
  still using GitHub-hosted `windows-latest` and `windows-11-arm` runners.
  This change aligns release builds with the faster dedicated Codex runner
  pool already used in CI, and adds machine-spec logging at startup so
  runner capacity (CPU/RAM/disk) is visible in build logs.
  
  ## What Changed
  
  - Updated the `build` job to support matrix entries that provide a full
  `runs_on` object:
    - `runs-on: ${{ matrix.runs_on || matrix.runner }}`
  - Switched Windows release matrix entries to Codex runners:
    - `windows-latest` -> `windows-x64` with:
      - `group: codex-runners`
      - `labels: codex-windows-x64`
    - `windows-11-arm` -> `windows-arm64` with:
      - `group: codex-runners`
      - `labels: codex-windows-arm64`
  - Updated the ARM-specific zstd install condition to match the new
  runner id:
    - `matrix.runner == 'windows-arm64'`
  - Added early platform-specific runner diagnostics steps
  (Linux/macOS/Windows) that print OS, CPU, logical CPU count, total RAM,
  and disk usage.

  Michael Bolin · 2026-02-11 12:53:03 -08:00
  444324175e
• feat: remove "cargo check individual crates" from CI (#11475)

  I think this check has outlived its usefulness. It is often one of the
  last CI jobs to finish when we put up a PR, so this should save us some
  time.

  Michael Bolin · 2026-02-11 10:19:29 -08:00
  0697d43aba
• ci: fall back to local Bazel on forks without BuildBuddy key (#11359)

  ## Summary
  - detect whether BUILDBUDDY_API_KEY is present in Bazel CI
  - keep existing remote BuildBuddy path when key is available
  - add a local fallback path for fork PRs without secrets by clearing
  remote cache/executor/BES endpoints
  - document each fallback flag inline with links to Bazel docs
  
  ## Testing
  - ruby -e 'require "yaml";
  YAML.load_file(".github/workflows/bazel.yml"); puts "ok"'
  - verified Bazel docs/flag references used in workflow comments

  Josh McKinney · 2026-02-10 23:19:55 +00:00
  34fb4b6e63