## 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
## What changed
Remove the contributor and secure devcontainer profiles, Dockerfiles, setup and firewall scripts, installation lockfiles, and documentation under `.devcontainer/`.
Remove the Dependabot devcontainers entry and redundant container-specific target directory rules from `codex-rs/.gitignore`.
GitOrigin-RevId: c0fe35b9a75468aab68b0aaaf08727a03d4b0ba0
## What changed
Remove `base_instructions` from `codex-rs/models-manager/models.json` and filter out the field in the `rust-release-prepare` workflow so automated catalog updates keep it excluded.
GitOrigin-RevId: 711d43c21a90aadc98e5622b8c24847bc4642c83
## 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
## Why
Artifact checksums alone do not authenticate the downloaded checksum manifest. V8 downloads need a trusted digest recorded in the repository, and published releases should not have their assets overwritten.
## What changed
- Pin the V8 `150.4.0` release manifest digests and verify manifests before downloading archives or bindings in packaging and `setup-rusty-v8`, preserving CRLF support.
- Refuse to replace published V8 releases, remove unfinished drafts on retry, and use `gh release create` to upload assets before publication.
- Install Windows `sccache` through a pinned `taiki-e/install-action` in the release and canary workflows.
- Document independent manifest verification and digest recording for version updates.
## Testing
Add five packaging tests covering successful downloads, CRLF manifests, tampered manifests, missing pins, and missing pin files. Rejection tests verify that artifacts are not downloaded.
GitOrigin-RevId: 5c771cdcff376388e124faa4826bf81135d84b50
## 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 `openDevices` and `setAudioControls` to the helper protocol. Open the default microphone and speaker after runtime initialization and transport negotiation, initially muted and suppressed.
- Use CPAL on macOS, GNU Linux, and MSVC Windows, with native audio dependencies confined to `codex-voice-host`. Add ALSA development dependencies to Linux CI.
- Pack callback samples into preallocated, bounded queues and service devices every 5 ms. Reject incompatible callback configurations, invalidate queued audio on control transitions, and reject capture backlog after unmute using device timestamps.
- Handle recoverable stream underruns and overruns without terminating the helper; terminate on device failure, active audio queue overflow, or stale queued audio.
Device opening only establishes local device readiness. Capture and rendered audio references are drained locally; encoding, decoding, and peer audio are not connected by this change.
## Testing
Add unit tests for mute boundaries, stale playback invalidation, sample bounds, partial-block packing and timestamps, callback size and timing limits, startup silence, queue overflow, and recoverable stream errors.
GitOrigin-RevId: 108aea3d411ef6c12908fe5fb67aaf9cddf4475f
## What changed
- Add the hidden `gpt-6-astra` model definition, including its reasoning levels,
tool capabilities, context limits, agent instructions, and review policies.
- Reorder existing model priorities around the new catalog entry and provide the
browser-use policy to the bundled auto-review model.
- Keep TUI snapshots pinned to `gpt-5.6-sol` and make Guardian coverage read the
policy from the model selected by each test case.
- Allow the expanded `models.json` through the repository blob-size check.
GitOrigin-RevId: 039b224b91ca35c8d894cf6d23568bc6dc18ceeb
## Why
The root Python formatting pass only covered `scripts/`, leaving Python utilities elsewhere in the repository outside `just fmt` and `just fmt-check`.
## What changed
- Run the scripts Ruff formatter from the repository root.
- Exclude `sdk/python`, which has its own formatter pass, and `codex-rs/vendor`.
- Apply Ruff formatting to the newly covered Python files and update the formatter coverage test.
GitOrigin-RevId: 73ac82b8bb9c713d589724f6c4f926399febb513
## 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
Community expertise is most useful when shared through detailed issue reports, reproduction steps, logs, analysis, and design discussion. Reviewing external code changes requires broader architectural and roadmap context and can divert maintainers from higher-priority work.
## What changed
- State that external code contributions and pull requests are not accepted.
- Replace invited-contributor workflow and CLA guidance with instructions for reporting bugs and requesting features through the issue tracker.
- Remove the pull request template and align the ChatGPT crate guidance with the repository-wide policy.
- Direct vulnerability reports to the security policy.
GitOrigin-RevId: 736c0cb181e07cc751bc46f4fefc53c6964e3dab
## 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
## What changed
- Write staged `rusty_v8` checksum manifests with LF line endings on every platform.
- Strip carriage returns when verifying manifests so existing Windows-built releases with CRLF line endings remain usable.
## Testing
- Assert that staged checksum manifests contain no carriage returns.
GitOrigin-RevId: 142855c147a08a60f5e5782c61e2fcd6b2e350d6
## 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 `install.sh` and `install.ps1` from stable release assets to the
mutable `codex/install.sh` and `codex/install.ps1` R2 keys.
- Require both installer assets and verify each uploaded object's size,
SHA-256 metadata, and CRC64 checksum before completing publication.
- Leave prerelease publication unchanged.
GitOrigin-RevId: 869f5fcd6c5f5d7fa4dc39c5216b31409d595fc9
## 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
The agent core team owns the core agent implementation and should review
changes to its adjacent runtime crates. Those crates were not covered by
the existing CODEOWNERS rules.
This adds `@openai/codex-core-agent-team` ownership for:
- `codex-rs/arg0`
- `codex-rs/codex-mcp`
- `codex-rs/exec-server`
## Validation
- `git diff --check`
No runtime tests are applicable because this only changes CODEOWNERS
metadata.
## 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`.
