## What changed
Install the `build-essential` package on apt-based runners in both full Rust CI workflows, including the platform-specific nextest workflow.
GitOrigin-RevId: 52e611235f032ed4a630301f40f8aafd9ca11a08
## What changed
Set `persist-credentials: false` for the V8 canary repository checkout and
for the `rusty_v8` checkouts in both the canary and release workflows.
GitOrigin-RevId: b4ccca7c7edf4e038b7b84c83f83d1416f655f65
## Why
Embedding reusable-workflow inputs directly in shell scripts can cause their
contents to be interpreted as shell syntax.
## What changed
- Export the Rust nextest target, profile, and test-thread inputs as environment
variables before using them in Bash commands and paths.
- Pass the MSVC target and host architecture to PowerShell through environment
variables.
GitOrigin-RevId: f96bbeeb7b556022e4bdea9db384a88f925050bf
## What changed
- Enable unprivileged user namespaces for every Linux job that uses the shared
`setup-ci` action.
- Disable AppArmor's unprivileged user namespace restriction when that sysctl is
available.
- Remove the duplicate setup from the two nextest workflow jobs.
GitOrigin-RevId: a5aebe0795ada435e687826134411c8b1c28bd98
## What changed
- Add `just assemble-codex-package` as the documented entry point for the package builder.
- Export `CODEX_REPO_ROOT` from `just` and release CI, and require the package builder to use it for repository-relative inputs.
- Resolve the ripgrep and zsh manifests relative to their Python modules.
GitOrigin-RevId: 039d12107a49171f064b0119adc6b99cf97c6c1e
## What changed
Remove the `repo-checks` steps that staged a Codex npm package from a fixed
release workflow and uploaded the resulting tarball as an artifact.
GitOrigin-RevId: bb3756188eeea2ed236710273234e70f17dc9e9d
## What changed
- Pin `openai-codex` to the `0.147.0` CLI runtime and regenerate its protocol models and lockfile.
- Allow stable Python SDK release tags and require their versions to match the pinned runtime.
- Expose the regenerated API additions, including thread sections, environment connection notifications, audio inputs, and the `section_id` thread-list filter.
## Testing
- Update release staging, generated-contract, notification, and public-signature coverage for the new runtime.
GitOrigin-RevId: 8b99ef6781e01c34d9d697c8c44247fb4e4fe3ab
## What changed
Update `pypa/gh-action-pypi-publish` from v1.13.0 to v1.14.2 for the Python runtime and SDK publishing jobs.
GitOrigin-RevId: 239d2787aec47fd53111e05c29efdd680c0c7c67
## Why
Release jobs download the `codex-zsh` manifest before packaging or signing its
bundled binaries. Verify that download against a pinned digest so an unexpected
manifest cannot enter release artifacts.
## What changed
- Pin the SHA-256 digest for the `codex-zsh-v0.1.0` manifest.
- Add a portable verification script that uses `sha256sum` or macOS `shasum`.
- Run verification in both the package archive and macOS helper signing flows.
GitOrigin-RevId: a404bb897c8cc0bf3c0ff38e8a6e1cce059d7fab
## What changed
- Load the Apple issuer ID from the notarization key's `apple-issuer-id`
tag alongside its key ID and pinned version.
- Require the tag to contain a valid UUID before creating the notarization JWT.
- Remove the separate `APPLE_NOTARIZATION_ISSUER_ID` environment variable and
release workflow secret wiring.
## Testing
- Cover valid, missing, empty, and malformed issuer ID tags in the macOS
notarization tests.
GitOrigin-RevId: c42da96a36293cf39312d8238f958f6898247f19
## Why
Checking only the pull request head can miss conflicts with changes already on
`main`.
## What changed
Remove explicit pull request head refs from required workflow checkouts so
GitHub Actions checks out the synthetic merge commit by default. Keep the
blocking gate on the same combined revision as the child workflows it
evaluates, and document the merge-commit policy in the workflow README.
GitOrigin-RevId: dc357caa5dc43f46b9b9a0edea6ee560b4fe8efb
## Why
Keep the App Store Connect private key in Azure Key Vault instead of exporting it to release runners as a base64-encoded `.p8` secret.
## What changed
- Add a notarization client that creates notary-scoped Apple JWTs with a pinned Azure Key Vault key, submits and streams artifacts to Apple's notarization service, polls for completion, and saves developer diagnostics.
- Update the binary and DMG release wrappers to use the new client while continuing to staple accepted DMGs with `rcodesign`.
- Configure release jobs with the notarization vault key name and version instead of private-key material.
## Testing
- Add unit coverage for key validation, JWT signing, uploads, polling, diagnostic logs, and the binary and DMG wrapper contracts.
GitOrigin-RevId: 8f526c5691d774964fd33f847f8420cac0840b05
## What changed
Run the hash-pinned `openai/fence` action in `audit` mode before checkout in
the blob size policy job.
GitOrigin-RevId: 9312897dae76d93298008b2ce8a8767680fe34b8
## Why
R2 publication waited for DotSlash to finish before uploading any release
assets, extending the release pipeline's critical path.
## What changed
- Start an `assets` stage after the GitHub release is created, in parallel with
DotSlash publication. Upload available assets concurrently without publishing
release metadata or channel aliases.
- Run a `finalize` stage after both jobs complete. Verify assets already present
in R2, upload any assets DotSlash added, and then publish metadata, stable
installer aliases, and release channels.
- Validate downloaded assets before upload and retain no-overwrite semantics
across both stages.
GitOrigin-RevId: 1c3e8ca715be4064c2532a5c651f1bbe03ed96a4
## Why
Code mode must link against a V8 build with sandbox support, but Windows MSVC
still used upstream non-sandboxed prebuilts and package builds selected the
older release artifact profile.
## What changed
- Enable the `v8_enable_sandbox` feature directly for the code mode runtime.
- Select the `ptrcomp_sandbox_release` archive and bindings in Cargo packaging
and CI, including Windows MSVC release builds.
- Point Bazel's Windows MSVC targets at the sandbox-enabled Codex artifacts and
enable the matching crate feature.
## Testing
Add a runtime test that calls `v8__V8__IsSandboxEnabled()` and verifies that
the linked V8 library has sandbox support enabled.
GitOrigin-RevId: c1b49b44a6ccfea5b5006d69ec7866848d1cddd7
## What changed
- Target `x86_64-pc-windows-msvc` in the post-merge native Windows Bazel job.
- Select the `//:windows_x86_64_msvc` target platform and the MSVC host platform.
- Update the job and execution-log artifact names to identify the MSVC target.
GitOrigin-RevId: ca7d65c8bc074dccb5e7ebbac3be80b97545a846
## Why
Linux release packages already include `codex`, `codex-code-mode-host`, and
`codex-resources/bwrap` in the `codex-package-<target>` archive.
## What changed
Remove the release workflow step that also created the redundant
`codex-<target>-bundle.tar.zst` archive for primary Linux builds.
GitOrigin-RevId: b4fd80e96b4fed991e9365e41fe7aad42a3fa28d
## What changed
Make the `update-branch` job wait for successful R2 publication before moving
`latest-alpha-cli`. For releases that publish npm packages, also require the npm
job to succeed; releases that intentionally skip npm publication can still
advance the branch.
GitOrigin-RevId: 38381b82c95c5c9650b2d72258ea7b835bdfa555
## Why
The Rust release workflow accepts alpha versions with a second numeric suffix,
such as `1.2.3-alpha.4.1`, but the R2 publisher rejects them as invalid.
## What changed
- Allow up to two numeric suffix components for alpha versions in
`publish_r2_release.py`.
- Document that its version pattern must remain aligned with release tag
validation in `rust-release.yml`.
GitOrigin-RevId: 8df68ce4f4d3e652367f7394a642827f21979d70
## Why
The macOS release workflow fetched `rg` and zsh while assembling package
archives, after the signing stage. This left the bundled helper executables
outside the workflow's signing and notarization checks.
## What changed
- Fetch, sign, notarize, and upload the pinned macOS `rg` and zsh binaries with
the other release artifacts.
- Build package archives from those signed helpers via `--rg-bin` and the new
`--zsh-bin` override.
- Verify the helpers' architecture, signatures, and absence of entitlements in
the final package.
## Testing
- Cover the prebuilt zsh override and verify that package assembly preserves
the supplied helper binaries.
GitOrigin-RevId: a3865c04fa2f0f4df32e627ee7202bc87bdc3241
## What changed
- Publish the verified `release.json` metadata to `codex/channels/latest` for
stable releases and `codex/channels/prerelease` for prereleases.
- Pass the release classification through the reusable R2 workflow so GitHub
Releases and R2 channels use the same stable-versus-prerelease decision.
- Allow channel objects to be replaced while keeping versioned release objects
immutable, and verify each channel upload before completing the publication.
GitOrigin-RevId: bd5c728c5565befe42b041ee1a032b111daca1c2
## What changed
- Add a reusable workflow that runs after the GitHub Release and DotSlash publishing jobs and mirrors each release asset to a versioned R2 prefix.
- Validate GitHub asset sizes and SHA-256 digests before upload, publish objects without overwriting existing files, and verify their remote size, digest metadata, and CRC64 checksum.
- Generate `release.json` with installer-facing asset URLs and digests, then publish and verify it alongside the release assets.
- Allow an in-progress Rust release workflow to finish instead of cancelling it when another run starts.
GitOrigin-RevId: e6717cd27914994accced6e2c5df696f0e9a558e
## Why
Windows Cargo and Bazel jobs spend significant time in filesystem-heavy
build and cache directories. Route those directories through one CI
build root so Windows can use its Dev Drive and Unix can use a stable
cache root.
## What
- Have `setup-ci` define `CI_BUILD_ROOT`, `CARGO_TARGET_DIR`, Bazel
cache/output paths, and temp paths.
- Require Windows to find or provision a verified Dev Drive instead of
falling back to `C:`.
- Pass the shared Bazel output base to `setup-bazel` so its explicit
`output_base` does not defeat Dev Drive routing.
- Point nextest, release, and V8 source-build paths at the shared
environment contract.
## Benchmark results
One-off cold-cache WPR/ETW traces show the explicit Bazel output-base
routing removes the dominant `C:` traffic:
| sample | `C:\_bazel` | summed `C:` traffic | traced test step |
|---|---:|---:|---:|
| shard 1 before | 62.2 GiB | 85.2 GiB | 16m22s |
| shard 1 updated | 0 | 16.5 GiB | 12m05s |
| shard 3 before | 67.2 GiB | 84.6 GiB | 16m48s |
| shard 3 updated | 0 | 13.5 GiB | 11m08s |
For a cold x64 V8 source build, the retained build-tail sample showed
`D:\cargo-target` at ~1.29 GiB while measured `C:` roots totaled ~0.45
GiB (`C:\Users` ~0.33 GiB, `C:\Program Files` ~0.06 GiB, `C:\Windows`
~0.03 GiB). The full cold build took 2h20m36s.
The Bazel timing improvement is directional because both refreshed
shards failed tests. The V8 trace is a bounded build-tail sample, not
the full build. All final samples had zero lost ETW events; VHDX traffic
was excluded from the optimization ranking.
Runs: [baseline
Bazel](https://github.com/openai/codex/actions/runs/28911908527),
[updated
Bazel](https://github.com/openai/codex/actions/runs/28917133701), [V8
build tail](https://github.com/openai/codex/actions/runs/28933626678).
## Manual validation
- Ran `just fmt`.
- Ran `just test-github-scripts` (35 tests).
- Parsed GitHub Actions YAML with `yq`.
- Ran `git diff --check`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
## Why
The V8 Windows source jobs need a runner image that can support the
later Dev Drive setup.
## What
Move the two V8 Windows source-build matrix entries from `windows-2022`
to `windows-2025`.
Namespace the canary source-build cache by runner image so it cannot
restore Windows 2022 native outputs.
## Manual validation
- Ran `just fmt`.
- Ran `just test-github-scripts` (33 tests).
- Parsed GitHub Actions YAML with `yq`.
- Ran `git diff --check`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
## Why
Prepare CI jobs for a later build-output relocation without changing
where they write today.
## What
- Export `CARGO_TARGET_DIR` from `setup-ci` at the existing
`codex-rs/target` path.
- Route nextest, release, artifact, and signing paths through
`CARGO_TARGET_DIR`.
- Require V8 staging callers to pass an explicit target directory while
preserving the existing upstream path.
## Manual validation
- Ran `just test-github-scripts`.
- Parsed GitHub Actions YAML with `yq`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
## Why
Intel macOS release binaries crash on the first Code Mode tool call
while V8 creates its code range. The x86_64 V8 allocator later makes a
non-`MAP_JIT` reservation executable, which Hardened Runtime rejects
when the signature contains only `com.apple.security.cs.allow-jit`.
Tracks
[SE-8006](https://linear.app/openai/issue/SE-8006/intel-macos-codex-cli-crashes-in-v8-startup-on-gpt-56-sol-tool-calls).
Fixes#28390.
## What
- add an expanded entitlement profile only for x86_64 `codex` and
`codex-app-server`, the release binaries that link V8
- keep arm64 and `codex-responses-api-proxy` on the existing narrower
profile
- share one fail-closed target/binary selector between signing and final
verification
- verify the expected Mach-O architecture and exact entitlement
dictionary for the signed binary, tar.gz, zstd, package, and DMG copies
## Verification
- `just test-github-scripts` (34 tests)
- `UV_CACHE_DIR=/private/tmp/codex-uv-cache just fmt-check`
- `bash -n .github/scripts/macos-signing/select_codex_entitlements.sh`
- `plutil -lint` on both entitlement profiles
- parsed `rust-release.yml` as YAML
- `git diff --check`
- ad-hoc Hardened Runtime signing smoke on an x86_64 Mach-O slice:
strict `codesign` verification passed; the Codex profile contained
exactly both keys and the proxy profile retained exactly `allow-jit`
## Release validation
Run a native Intel smoke of the final Developer ID-signed x86_64 Codex
binary through V8 isolate creation before shipping. PR #30849 is
diagnostic scaffolding, but its non-sandbox release job currently fails
in the harness before V8 starts, so it is not counted as coverage here.
## Why
CI jobs repeat common bootstrap steps, which makes it harder to keep
Bazel and Cargo lanes aligned. Centralizing the lightweight setup gives
us one place for future runner-wide optimizations without adding Rust
toolchain or component installation to the Windows Bazel long poles.
## What
- add zero-input `.github/actions/setup-ci` to set Cargo's git
transport, install DotSlash and `just`, expose DotSlash from stable PATH
locations, and enable Windows Git long paths
- have `setup-bazel-ci` compose the common setup, then remove its
DotSlash/test-prerequisite plumbing
- migrate Bazel, Cargo CI, V8 canary, repo checks, nextest, and Windows
release call sites while keeping Rust toolchain and MSVC setup explicit
- preserve the existing nextest Dev Drive setup unchanged
## Validation
- `just test-github-scripts` (30 tests)
- parsed workflow and composite-action YAML with `yq`
## Summary
- build, strip, sign, and publish `codex-code-mode-host` with the
primary Codex release binaries on Linux, macOS, and Windows
- place the host beside `codex[.exe]` in canonical package archives,
macOS DMGs, and the legacy Linux bundle so the runtime's sibling lookup
succeeds
- preserve and validate the host through standalone installers and
Python runtime wheel staging
- add package-builder coverage for source selection and the resulting
package layout
## Why
The process-owned code-mode client launches `codex-code-mode-host` as a
sibling of the running Codex executable. Release artifacts currently
build and bundle `codex` without that host, so code mode cannot start
from installed packages.
## Why
The standalone installers currently perform separate unauthenticated
GitHub REST API lookups while resolving the latest version, locating the
platform package, locating its checksum manifest, and retrieving asset
digests. A single install can therefore make up to four release-metadata
requests.
When GitHub's shared unauthenticated rate limit is exhausted, valid
releases fail to install. The shell installer also suppresses the
metadata request failure while probing assets, so a `403` is misreported
as though the release assets do not exist. This makes the failure both
more likely and harder to diagnose.
Fixes#28538.
## What changed
- Resolve the selected version and fetch its release metadata together.
- Reuse that one metadata response for package, checksum, and
legacy-package selection in both `install.sh` and `install.ps1`.
- Report metadata fetch failures as possible GitHub availability or
rate-limit failures instead of missing assets.
- Add a mocked-`curl` regression suite covering exact releases,
`latest`, and a simulated metadata `403`, and run it in `repo-checks`.
For `latest`, the metadata returned by `/releases/latest` now supplies
both the resolved version and the asset list. For an explicitly selected
version, the installer makes one request to that release's tag endpoint.
## Verification
- `python3 -m unittest discover -s scripts/install -p 'test_*.py' -v`
- `sh -n scripts/install/install.sh`
- Parsed `scripts/install/install.ps1` with the PowerShell language
parser.
## Scope
This change reduces GitHub API usage and preserves the underlying error,
but it does not move release artifacts away from GitHub's CDN.
## Summary
AWS Bedrock issues currently fall under broader labels, which makes
provider-specific reports harder to find. The issue tracker now has an
`aws-bedrock` label, but the automated labeler does not know to apply
it.
Teach the issue labeler to select `aws-bedrock` for Amazon Bedrock
provider or Bedrock Mantle issues while excluding generic AWS
references.
## Why
It's hard to change the set of required jobs when they're managed in the
GitHub UI, and when each workflow is responsible for choosing it's own
scheduling it's easy to end up with skew between what we enforce on PRs
vs. on main.
## What
- add a `blocking-ci` caller workflow, triggered by pull requests and
pushes to `main`, for Bazel, blob size, cargo-deny, Codespell,
`repo-checks`, rust CI, and SDK CI
- add an `always()` terminal job named `CI required` that fails unless
every called workflow succeeds
- add a `postmerge-ci` caller workflow for `rust-ci-full` and
`v8-canary`, with a terminal `Postmerge CI results` job
- centralize V8 relevance detection in `v8_canary_changes.py`; unrelated
PR and postmerge runs execute metadata only and skip the expensive build
matrices
- leave `v8-canary` outside the blocking gate and leave the external
`cla` check independent
## Rollout
A repository admin must replace the existing required GitHub Actions
contexts with `CI required` in the main-branch ruleset. Retain `cla` as
a separate required check. Until that change is coordinated, this PR
cannot satisfy the old standalone check names. In-flight PRs will need
to be rebased after this lands.
## Why
Once #30114 publishes zsh independently, regular Rust releases should
reuse that protected, versioned artifact set instead of rebuilding
identical zsh binaries for every Codex version. Keeping the zsh release
tag explicit in the workflow also makes future artifact upgrades
deliberate and easy to review.
This PR assumes the first standalone artifact release will be published
as `codex-zsh-v0.1.0` before this change lands.
## What changed
- Added `CODEX_ZSH_RELEASE_TAG` near the top of
`.github/workflows/rust-release.yml`, initially pinned to
`codex-zsh-v0.1.0`.
- Download the standalone release’s generated `codex-zsh` DotSlash
manifest before assembling Linux and macOS Codex packages.
- Added a `--zsh-manifest` package-builder override so release packaging
fetches the matching target archive and verifies the size and SHA-256
digest recorded in that manifest.
- Removed the reusable zsh build job from regular Rust releases.
- Stopped copying zsh archives into each Rust release and stopped
regenerating a zsh DotSlash manifest there.
Windows packaging remains unchanged because the patched zsh resource is
only shipped for supported Unix targets.
## Testing
- Added package-helper coverage that supplies a standalone manifest
override and verifies the extracted zsh bytes.
- Ran the `scripts/codex_package` unit test suite.
- Validated `.github/scripts/build-codex-package-archive.sh` with `bash
-n`.
## Why
The patched zsh artifacts rarely change, but
`.github/workflows/rust-release-zsh.yml` currently runs as part of every
Rust release. Rebuilding the same four binaries for each Codex version
wastes release capacity and ties an independently versioned runtime
dependency to the main release cadence.
This establishes the producer side of a build-once flow. The existing
Rust release workflow remains unchanged until the first standalone
artifact release has been published and the checked-in DotSlash
manifests can be updated with its URLs and checksums.
## What changed
- Run the zsh release workflow for protected `codex-zsh-vX.Y.Z` tags
instead of as a reusable workflow.
- Validate the semantic release tag before starting the platform builds.
- Publish the four zsh archives to a GitHub prerelease so the release
never becomes the repository latest release.
- Publish the generated `codex-zsh` DotSlash manifest alongside the
archives.
- Document how to publish the next artifact version after changing the
pinned zsh commit or patch.
## Tag protection
An active repository tag ruleset named `codex-zsh-v*.*.*` targets
`refs/tags/codex-zsh-v*.*.*`. It restricts tag creation, updates,
deletion, and non-fast-forward changes; requires linear history; and
limits bypass to the configured repository role.
This was verified with:
```shell
gh api repos/openai/codex/rulesets/18140982
```
The response reported `"enforcement":"active"`, the expected tag
condition, and the `creation`, `update`, `deletion`, `non_fast_forward`,
and `required_linear_history` rules.
## Rollout
After this lands, publish the first `codex-zsh-vX.Y.Z` release. A
follow-up can then update the checked-in DotSlash manifests and remove
the zsh rebuild from `.github/workflows/rust-release.yml`.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/30114).
* #30116
* __->__ #30114
## Why
CI jobs should not silently leave tracked changes or untracked files in
the repository worktree.
## What
- Add a shared final worktree-cleanliness action to 19 checkout-bearing
PR and main CI jobs.
- Ignore the intentional SDK scratch directory and nested V8 checkout.
- Pin Bazelisk in shared CI setup so `.bazelversion` remains
authoritative, avoiding `MODULE.bazel.lock` deltas on Windows runners.
- Leave `rust-ci-full` and release-only workflows unchanged.
- Update `AGENTS.md` to discourage review bots from asking for
`MODULE.bazel.lock` changes.
The custom Windows argument-comment-lint job was temporarily moved to
`windows-2022` in #28940 after hermetic LLVM source extraction failed on
the newer runner. This takes the upstream extraction fix so the job can
return to the intended custom runner.
This upgrades `llvm` to `0.7.9` and `rules_cc` to `0.2.18`, refreshes
the module lock, rebases the remaining Windows and custom libc++
patches, drops the obsolete symlink-extraction workaround, and restores
the `windows-x64` runner configuration.
Validation:
- Verified all LLVM patches apply cleanly against the `0.7.9` source.
- Built `@llvm-project//compiler-rt:clang_rt.builtins.static`.
## What
Run the Windows argument-comment-lint job on the `windows-2022` hosted
runner instead of the custom Windows runner pool.
## Why
The custom pool recently moved from the Visual Studio 2022 Windows image
to `windows-2025-vs2026`. Since that migration, the job fails while
Bazel materializes LLVM external repository sources, before the argument
lint itself runs. The same failure appears across unrelated PRs.
This narrow change tests GitHub’s recommended mitigation for workloads
that still require the Visual Studio 2022 image:
https://github.com/actions/runner-images/issues/14017
## How
Use the standard `windows-2022` runner for only the Windows
argument-comment-lint matrix entry. No product code or lint behavior
changes.
## Why
We want to exercise a linux app-server against a windows exec-server
without having to repeat every test case. This approach has slight
precedent in the remote docker test setup.
## What
Run the shared `codex-core` integration suite against Windows
exec-server behavior from Linux. This makes cross-OS path and shell
regressions visible while keeping unsupported cases owned by individual
tests.
- Add `local`, `docker`, and `wine-exec` test environment selection with
legacy Docker compatibility.
- Extend `codex_rust_crate` to generate a sharded Wine-exec variant
using a cross-built Windows server and pinned Bazel Wine/PowerShell
runtimes.
- Teach remote-aware helpers about Windows paths and track temporary
incompatibilities with source-local `skip_if_wine_exec!` calls and
follow-up reasons.
## Intent
Keep Bazel and Starlark files consistently formatted without requiring
contributors to install or version buildifier themselves.
## Implementation
- Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
v8.5.1.
- Run buildifier from the shared `just fmt` and `just fmt-check` driver,
with Windows-safe explicit DotSlash invocation.
- Provision DotSlash in formatting CI and contributor devcontainers, and
document the source-build prerequisite.
- Apply the initial mechanical buildifier formatting baseline.
The first release after parallelizing Windows packaging moved the
critical path to the ARM64 packaging job:
https://github.com/openai/codex/actions/runs/27451157324
The x64 job started immediately and finished in 5m29s. The ARM64
job waited 76s for its runner and then took 5m56s, holding the
release for 1m43s after x64 had finished.
Packaging only downloads, signs, archives, and compresses already
built binaries. It does not execute target code. Run both packaging
jobs on x64 runners, keeping ARM64 hardware for compilation.
In the Windows x64 packaging job from
https://github.com/openai/codex/actions/runs/27391514823
building the primary and app-server package archives serially took 116
seconds.
Both archives read the same signed-binary directory but write separate
package trees and output files. Run them concurrently with xargs -P2.
The package helper rewrites DotSlash executables under the process temp
directory. A naive concurrent run failed when one process tried to
replace an executable used by the other. Give each bundle separate TMP
and TEMP roots to keep those caches independent.
On Windows x64 in
https://github.com/openai/codex/actions/runs/27397197944
three serial trials took 127, 128, and 126 seconds. Concurrent trials
took 76, 74, and 74 seconds, saving 52 to 54 seconds. This removes about
50 seconds from the release critical path without changing the packaging
commands or output set.
In the x64 packaging job from
https://github.com/openai/codex/actions/runs/27391514823
archiving and uploading PDBs took 65 seconds after signing. Release
packaging could not start until that work completed.
Windows code signing changes executables but not their PDBs. Package
the PDBs in a sibling Ubuntu job as soon as all binary artifacts are
available. Signing and release packaging can then proceed without
waiting for the symbols archive, reducing the critical path by about
one minute.
Each Windows packaging job creates three compressed forms of five
binaries in sequence. This takes roughly two minutes and is on the
release critical path.
Use two xargs workers to compress independent binaries concurrently.
The workers only read the raw executables and write per-binary archive
names. The Codex zip can safely read the helper executables while their
own archives are generated.
On a 16-vCPU AMD EPYC 9V74 Windows x64 release runner, alternating
trials against artifacts from release run 27391514823 measured:
serial: 121 s, 123 s, 121 s
parallel: 73 s, 73 s, 74 s
This saves 47 to 50 seconds in the x64 packaging lane, reducing the
observed release critical path by about 48 seconds when x64 remains the
limiting lane.
https://github.com/openai/codex/actions/runs/27401905938
## Summary
`just fmt` previously used `uv run --with ruff` to make Ruff available.
Because `--with` creates an ephemeral overlay outside the project
lockfile, uv periodically re-resolved Ruff (by default every 10 minutes)
instead of using the version recorded in `uv.lock`.
Move the Python SDK tooling dependencies from the published `dev` extra
into `format`, `test`, and composed `dev` dependency groups. The
formatter now selects only the locked `format` group, contributor and CI
setup explicitly sync the `dev` group, and CI and release commands reuse
that environment with `--frozen --no-sync`. The scripts formatter also
uses its project's locked Ruff dependency instead of an ephemeral
overlay.
Validated the Python 3.12 SDK suite (119 passed, 38 skipped) and the
repository formatter.
Issues written in languages other than English, such as #26979, require
manual translation before the development team can triage them.
This adds an `Issue Translator` workflow that uses Codex when an issue
is opened. For non-English reports, it replaces the title with an
English translation, preserves the original body, and posts the
translated body as an idempotent issue comment.
The translation scripts were run manually against non-English issue
content and produced the expected English title and comment output.
Avoid rebuilding sandboxed Windows MSVC V8 artifacts for unrelated
changes to `codex-rs/Cargo.toml`.
The V8 canary now compares the resolved V8 version between the base and
head commits and only runs the Windows source-build matrix when:
- the resolved V8 crate version changes;
- Windows artifact-production scripts or workflows change; or
- the workflow is manually dispatched.
The existing Bazel V8 matrix is unchanged.
## Why
The Windows MSVC source builds take roughly two to three hours and
currently run whenever any entry in the broad `v8-canary` path filter
changes.
In https://github.com/openai/codex/actions/runs/27354608310, the
concurrency introduced by
5e50e7e639
caused the npm publish job to fail.
The six platform tarballs contain different versions of the same
`@openai/codex` package. Every publish updates the same packument, so
only two concurrent updates succeeded while four failed with HTTP 409.
Serializing that group would leave only the responses API proxy running
in parallel. Saving one publish does not justify the nested `xargs`
machinery needed to express those groups.
Restore the serial publish loop and document why the platform variants
must not publish concurrently. Platform packages remain ahead of the
root CLI wrapper, and the SDK remains after its exact root dependency.
In https://github.com/openai/codex/actions/runs/27308011621, the
release job downloaded 10.0 GiB of workflow artifacts in 87 seconds,
then discarded 42 artifacts accounting for 3.3 GiB.
Select target and supplemental release artifact patterns at download
time. This also excludes duplicate Cargo timing files without a cleanup
pass and should reduce total release time by about 30 seconds.
