## What changed
Pass `BUILDBUDDY_API_KEY` to Linux, macOS, and Windows voice release builds, and give the dedicated macOS and Windows voice jobs access to the `bazel` environment without creating deployments.
Use the shared Bazel preparation action and BuildBuddy wrapper for Linux and macOS voice builds so they inherit the existing repository cache and remote cache configuration.
GitOrigin-RevId: 52cdf05bc4567f3e8c460d2509e57bb30e667868
## Why
Publishing a draft prerelease emits a `published` event instead of a `prereleased` event.
## What changed
Create GitHub prereleases with `--draft=false` so they emit `prereleased` events. Keep stable releases as drafts until all asset uploads succeed.
GitOrigin-RevId: 145fd84f852d7ee9cb3c4edff7007a34c3389e1c
## Why
Prereleases were published before their assets finished uploading, exposing incomplete releases.
## What changed
Create new prereleases as drafts, matching stable releases, and publish them only after all asset uploads succeed. Publishing a draft emits a `published` event rather than a `prereleased` event.
GitOrigin-RevId: 0d1c52038bb9b7beb4b5b9bf52f0ef4c3734de61
## What changed
- Attempt each `npm publish` up to three times, with 10- and 20-second delays and fresh OIDC credentials on each attempt. Continue skipping already-published versions.
- Enable verbose npm logging and retain debug logs as artifacts for seven days, including on failure.
- Use `macos-15-intel` to verify provisioned `x86_64-apple-darwin` packages, while keeping `aarch64-apple-darwin` verification on `macos-15-xlarge`.
GitOrigin-RevId: 1876c66993ecd8cdb44088ab17a3363d21135ec4
## What changed
Replace `softprops/action-gh-release` in `.github/workflows/rust-release.yml` with explicit `gh` commands:
- Look up the release by tag, including drafts, and fail on API errors.
- Create stable releases as drafts until assets are uploaded. Create prereleases directly to preserve prerelease events.
- Upload sorted assets with `--clobber`, then publish the release with the configured title, notes, prerelease status, and latest status.
- Cap release notes at 124,999 characters, including a trailing newline.
GitOrigin-RevId: f343e4f265b06e047d85fe5a2b89a92690c7a7fb
## Why
Parallel Bazel artifacts are advisory while Cargo remains the release path.
## What changed
- Set `continue-on-error` for Bazel matrix jobs covering builds, Windows symbols and signing, and macOS signing, packaging, and verification.
- Assign the main release build jobs in both workflows to the `bazel` environment with `deployment: false`.
GitOrigin-RevId: e8a0fd522ec6482c0f39abdfc8677018be409361
## What changed
Remove the patched `zsh` resource from package assembly and macOS signing, along with the `--zsh-bin` and `--zsh-manifest` packaging options.
Delete the standalone `codex-zsh` release workflow, build scripts, and DotSlash manifests. Update package documentation and layout and signing tests to match the remaining resources.
GitOrigin-RevId: 429a8db55048fed7facec89957910206523b6013
## What changed
- Add Cargo and Bazel build matrices for Linux, macOS, and Windows, carrying both through signing, packaging, and artifact verification.
- Publish Bazel binaries, packages, and symbols with a `-bazel` suffix while preserving Cargo artifact names. Keep Python runtime wheels and the Windows installer on the Cargo path.
- Use `--config=release` for native voice builds and Windows voice tests, set the macOS voice build minimum to 14.0, and increase the Windows binary build timeout to 120 minutes while both build paths coexist.
GitOrigin-RevId: 77bcdd7b2a573d0ae2a4c3392e0708445b386f23
## Why
Release builds for different tags can run concurrently, but publication must remain serialized so channel checks and updates cannot race or move release pointers backward.
## What changed
Scope workflow concurrency to `${{ github.workflow }}-${{ github.ref }}`. Keep `release`, `publish-r2`, `publish-npm`, `winget`, and `update-branch` on a shared `rust-release` concurrency group with `queue: max` and `cancel-in-progress: false`.
GitOrigin-RevId: 75b42fd765db6091fb9190aae2ecccd2bb959d08
## Why
Publishing an older stable version should not replace a newer release as the default download or installation target.
## What changed
- Compare stable versions before marking a GitHub release as latest, allowing same-version reruns to finish publication.
- Guard npm `latest` and platform dist-tags, publishing older versions under separate `release-<version>-<tag>` tags.
- Check R2's `latest` channel before updating it or the installer aliases, while allowing same-version reruns to repair interrupted installer updates.
- Reject invalid existing stable release metadata and consolidate GitHub latest and canary checks in `releases.py`.
## Testing
Add regression tests for stable version ordering, same-version reruns, npm package and platform tags, and invalid channel metadata. All 21 tests in `.github/scripts/test_releases.py` pass.
GitOrigin-RevId: e6bad3ee163b279ac1661b9070712a41eedd50ff
## What changed
Extend the Windows signing action with an `additional-files` input and sign `scripts/install/install.ps1` with Azure Trusted Signing in the x64 release job. Stage the architecture-independent installer after compression so it remains a plain script, and publish the signed artifact as `install.ps1` instead of copying the unsigned source.
## Testing
The Windows release workflow verifies that the installer has a valid Authenticode signature and a timestamp certificate before staging it, failing the job if either check fails.
GitOrigin-RevId: 6f16a084b8f350fbf3644c36d75651a6f4b88506
## Why
Publishing an older alpha or alpha hotfix can overwrite npm dist-tags that already point to a newer release.
## What changed
Check each package's current npm dist-tag before publishing an alpha release, using the existing release version comparison and workflow concurrency lock. Handle `alpha` and platform-specific tags independently for Codex, the SDK, and the responses API proxy.
When the release does not advance the current version, publish under `release-<version>-<tag>` to keep it installable without changing the alpha or `latest` tags. Abort publishing if the registry lookup fails.
## Testing
Add unit tests for package and platform tag selection, older releases, dotted alpha hotfixes, missing tags, and registry lookup failures.
GitOrigin-RevId: 9c0edec1149bf78c01aac0f700e963630316eaea
## Why
Publishing a hotfix for an older release line or alpha can replace a newer prerelease pointer. Release pointers should advance according to version order.
## What changed
- Share release version validation and numeric comparison across publishing scripts, including alpha hotfix suffixes and alpha, beta, and stable ordering.
- Read the prerelease pointer directly from R2 and update it only for a newer version or missing or invalid version metadata.
- Restrict `latest-alpha-cli` updates to alpha releases with successful R2 and npm publishing, and compare against the branch's Cargo version before advancing it. Allow replacement when the manifest version cannot be parsed or validated.
## Testing
Add 15 passing unit tests covering version validation, older release lines and alphas, numeric hotfix ordering, prerelease precedence, equal versions, and missing or invalid versions.
GitOrigin-RevId: 6bee3906a47f613b662ef2b2224cfcbd1b56650c
## Why
The WinGet Releaser action references `cargo-binstall@main`, violating the requirement for full commit SHA action pins.
## What changed
Replace the action with explicit steps that install SHA-pinned `cargo-binstall` version `1.23.0` and `komac` version `2.16.0`. Discover the published Windows archive URLs and require two matching assets before submitting the `OpenAI.Codex` update.
Use `komac` to sync the publishing fork, submit the WinGet update, and clean up merged branches.
GitOrigin-RevId: da4da51937a372b841f42420b5bf775a9c151e4e
Upgrade `softprops/action-gh-release` from `v2.6.1` to `v3.0.3` and enable
`preserve_order` in the Rust release workflow to upload assets serially,
following GitHub's recommendation to avoid concurrent REST API requests.
GitOrigin-RevId: d1fbbbb01e191967be303040cfa2949146a2292d
## Why
A release can succeed with the optional `provisioned-macos-candidate` job
skipped. R2 publishing needs explicit status conditions to avoid inheriting
GitHub Actions' default skip behavior from upstream jobs.
## What changed
Add `!cancelled()` and explicit dependency success checks to both R2 jobs in
`.github/workflows/rust-release.yml`. Asset publishing requires `release` to
succeed; finalization also requires `publish-dotslash` and `publish-r2-assets`
to succeed.
GitOrigin-RevId: dbb975b79592df26d128ebf5ea770d92555d431d
## What changed
Set the `publish-dotslash` job condition to `!cancelled() && needs.release.result == 'success'` so it runs after a successful release unless the workflow is cancelled.
GitOrigin-RevId: 38e7a00fc50839b660e2d0cfed71002338387ffe
## What changed
- When `CODEX_PROVISIONED_MACOS_CANDIDATE` is `true`, require the provisioned macOS job to succeed and upload its verified packages as release assets. Allow releases to proceed when the job is disabled and skipped.
- Include provisioned archives in `codex-package_SHA256SUMS` and remove per-architecture `SHA256SUMS` files before upload.
- Publish a `codex-provisioned` DotSlash manifest for macOS ARM64 and x86_64 packages, pointing to `bin/codex`.
GitOrigin-RevId: 7e36df484a3b7da6b66180fa31418a6958d1fe77
Download target artifacts, supplemental release assets, and staged npm
packages in a single `actions/download-artifact` step in
`.github/workflows/rust-release.yml` using a combined artifact pattern.
GitOrigin-RevId: 64c63cc7a2e263418b2a4064c1fd46e1c514cc29
## Why
Avoid rebuilding the upstream Docker image and downloading its apt dependencies for each release by using the Python and `gh` already available on Ubuntu runners.
## What changed
Add a shared composite action that checks out the pinned upstream publisher and uses pinned `uv` to install hash-verified Python dependencies from wheels in a virtual environment. Accept multiple configuration paths and publish each manifest for the requested tag.
Update the Rust and zsh release workflows to use the action, combining the Codex and argument-comment-lint manifests into one invocation.
GitOrigin-RevId: 2a7ffef9a076a1d426349bcea587b10599cb8175
## Why
Linux voice needs system ALSA plugins and enough buffering to accommodate PipeWire graph cycles without losing capture samples. Voice startup failures also need actionable diagnostics without exposing native error details.
## What changed
- Build and bundle GNU voice helpers and runtimes with primary Linux musl release archives, and sign the archives. Keep Python wheels free of these libraries to preserve `manylinux_2_17` compatibility.
- Discover ALSA plugins in fixed system directories and increase Linux capture and playback buffering to support larger PipeWire graph cycles.
- Report voice failures by stage, preserve negotiation timeout classification, and discard native error sources. Suppress the misleading `requested` closure message after failure cleanup.
- Add explicit Windows MSVC, pkgconf, and CMake toolchain configuration and preserve host architecture in native build environments.
## Testing
Add coverage for Linux release assembly, ALSA plugin discovery, PipeWire capture and playback, classified startup failures, failure cleanup rendering, and Windows build environment handling.
GitOrigin-RevId: d805eace96a669ce3a4489f12e2db6f68f9f7f53
## What changed
- Add a tag-release workflow gated by `CODEX_PROVISIONED_MACOS_CANDIDATE` for Apple Silicon and Intel macOS candidate artifacts.
- Package the CLI in `CodexCLI.app` with an embedded provisioning profile and a relocatable `bin/codex` launcher. Validate independently supplied profile, certificate, and team expectations before signing.
- Sign and notarize candidates, then verify signatures, entitlements, architecture, stapling, and Gatekeeper acceptance on macOS. Retain verified artifacts after package smoke tests pass.
- Filter code-mode smoke-test requests to `/v1/responses` so analytics requests are excluded from response parsing.
## Testing
Add tests for profile validation, launcher relocation and symlink handling, standard and provisioned signing flows, and rejection of signing, notarization, identity, and entitlement failures. The candidate workflow runs package smoke tests, including sandboxed code mode.
GitOrigin-RevId: f214f6a23dd10df62cd72a2c63c20cb0864fbc9c
Guard the `voice_args` array expansion to avoid unbound-variable errors
under `set -u` when packaging bundles without voice arguments. Preserve
quoted arguments for the `primary` bundle.
GitOrigin-RevId: 677a565d1678dc1e218cd9a98298aa6a26873643
## Why
GNU tar extraction and signing require writable copies of Bazel outputs.
## What changed
Recursively add owner write permission to the staged macOS voice runtime before creating the unsigned release archive.
GitOrigin-RevId: 1d415251b26303ac17cf886f35ae18277e9e6032
## What changed
- Build the voice host and native runtime with Bazel's `-c opt` configuration.
- Resolve runtime paths before validating their contents in the release workflow.
- Make `runtime.json` owner-writable before sealing the post-signing release receipt.
- Use `scripts` in `PYTHONPATH` so archive creation can import `codex_package.archive`.
GitOrigin-RevId: 02f960573a4151f52cde486e17e1d45b73435306
## Why
Release tags bump `Cargo.toml` versions without updating the workspace lockfile, leaving stale versions for Bazel's Cargo dependency graph.
## What changed
Run `cargo update --workspace` in `codex-rs` before the macOS voice release job builds the voice host and native runtime with Bazel.
GitOrigin-RevId: ed923530ff5bc9982968cac4f1def4dde379f422
## What changed
- Build, sign, and notarize `codex-voice-host` and its native runtime for Apple Silicon and Intel macOS release packages, granting the helper audio-input access.
- Include voice resources in primary package archives and DMGs, with a root-level `codex` symlink to `bin/codex` so the runtime can be located.
- Seal runtime receipts with post-signing hashes, require matching release versions and source builds, and bundle dependency notices, licenses, and source metadata.
- Keep voice resources out of Python wheels to preserve their older macOS compatibility; the native voice build targets macOS 14.
## Testing
Add packaging tests for alpha, beta, and stable versions, signed-byte preservation, license hashes, receipt validation, tamper detection, and exclusion of unlisted files. Extend release verification to check voice architectures, signatures, build identity, package hashes, and DMG contents.
GitOrigin-RevId: 9f9415a8b2532d655a9a8740bcdf64066ddb7472
## Why
Executor compatibility checks need a build identity that distinguishes commits
and compiler targets independently of the package release version.
## What changed
- Add optional `providerId` to exec-server environment metadata, cached at startup
and returned by initialization and `environment/info`.
- Derive the ID as SHA-256 of `git:<lowercase commit>:<target>`. It identifies a
standard build configuration, not exact executable bytes, and is omitted when
the commit stamp or target is unavailable or invalid.
- Embed the compiler target in `BuildInfo`, preserve compatibility with historical
metadata without a target, and stamp Cargo release builds with `STABLE_GIT_COMMIT`.
- Group Bazel build-script argument files under one `--arg-file` flag to reduce
Windows command-line length while preserving file order.
## Testing
Add deterministic build-ID vectors across targets, commit normalization and invalid
input coverage, and historical metadata compatibility tests. Extend exec-server
coverage for metadata caching and ensure runtime environment overrides cannot
replace the executor's build identity.
GitOrigin-RevId: 125a18c23de7ad006571940ba305836376c983f4
## What changed
- Stage npm tarballs in a job with `contents: read` permissions and upload them as the `npm-packages` artifact.
- Require staging to succeed before the `release` job runs, and download the staged tarballs there. Remove its dependency installation, packaging steps, and `actions: read` permission.
- Reuse native artifacts from `--artifacts-dir` when every target directory is nonempty, skipping workflow lookup and download. Retain workflow-based downloads as a fallback.
GitOrigin-RevId: 89c6a5039afbac12968fb6f35a39c8db723c4c62
## 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
## 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
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
## 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
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
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.
## 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
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`.
In https://github.com/openai/codex/actions/runs/27354608310, the
concurrency introduced by
https://github.com/openai/codex/commit/5e50e7e639c9284ceac24a5498b73a5602fb6615
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.
In https://github.com/openai/codex/actions/runs/27308011621,
preparing and publishing the three DotSlash configurations took 72
seconds after creating the GitHub release. npm publication could not
start until those independent steps finished.
Move DotSlash publication to a sibling job that starts after the GitHub
release. npm and DotSlash can then proceed concurrently, reducing total
release time by about one minute.
In https://github.com/openai/codex/actions/runs/27308011621,
publishing the npm tarballs serially took 147 seconds. Six platform
packages and the responses API proxy are independent.
Publish those packages concurrently, then publish the root CLI wrapper
and SDK in dependency order. Individual platform publishes took 19 to
23 seconds, so this should reduce total release time by nearly two
minutes.
The release job already downloads every workflow artifact into `dist`,
but npm staging creates a new cache and downloads the six target
artifacts again.
Reuse `dist` as the staging script's artifact cache while preserving the
existing download fallback for missing artifacts and standalone callers.
The script retains ownership of temporary caches but does not delete a
caller-provided directory.
In https://github.com/openai/codex/actions/runs/27242495616, the
duplicate
download transferred 3.3 GiB and took 4 minutes 13 seconds. This should
reduce total release time by about 4 minutes.
## Why
These workflows currently hard-code the `codex` runner group and custom
runner labels. That makes the same workflow definitions less portable
across repository copies or renamed repos, even though the runner fleet
follows the repository name scheme. Template the runner identities from
the repository name so `openai/codex` still resolves to the existing
`codex-*` runners while other repos can use their own `<repo>-*` runner
names.
## What Changed
- Replaced custom runner `group` values such as `codex-runners` with
`${{ github.event.repository.name }}-runners`.
- Replaced custom runner labels such as `codex-linux-x64` and
`codex-windows-arm64` with `${{ github.event.repository.name }}-...`.
- Covered direct `runs-on` objects, matrix `runs_on` entries, reusable
workflow runner inputs, and release runner labels.
## Verification
- Parsed all `.github/workflows/*.yml` files as YAML with Ruby.
- Searched `.github/workflows` to confirm no hardcoded runner-field
`codex-runners` or `codex-*` labels remain.
Adam Perry @ OpenAI