167 Commits

• Use Winget release environment secret (#26466)

  ## Why
  `WINGET_PUBLISH_PAT` now lives as a GitHub environment secret under
  `mainline-release-winget`. The WinGet release job needs to enter that
  environment so `secrets.WINGET_PUBLISH_PAT` resolves during
  stable/mainline Rust releases.
  
  ## What Changed
  - Attach the `winget` job in `.github/workflows/rust-release.yml` to the
  `mainline-release-winget` environment.
  - Set `deployment: false` so the job can read environment secrets
  without creating GitHub deployment records.
  
  ## Operational Note
  The `mainline-release-winget` environment must allow `rust-v*.*.*` tag
  refs before this can run on release tags. The live environment currently
  has a custom policy named `rust-v*.*.*` with type `branch`; add the
  corresponding `tag` policy before relying on this path for a release.
  
  ## Validation
  - `git diff --check origin/main...HEAD --
  .github/workflows/rust-release.yml`
  - `ruby -e 'require "yaml"; ARGV.each { |f| YAML.load_file(f); puts
  "yaml ok: #{f}" }' .github/workflows/rust-release.yml`

  Shijie Rao · 2026-06-04 14:38:11 -07:00
  37c8aefa14
• build: use ThinLTO for release binaries (#23710)

  ## Why
  
  Fat LTO makes release builds substantially slower without providing
  enough measured runtime benefit to justify the release CI long pole. The
  build-profile investigation found that keeping Cargo's default release
  `opt-level=3` and switching from fat LTO to ThinLTO (`3/thin/1`) reduced
  a clean `codex-cli` release build from 2073.893 seconds to 1243.172
  seconds, a 40.06% improvement.
  
  The resulting binary increased from 196.7 MiB to 211.8 MiB (+7.63%).
  Measured runtime changes were small: the worst image workload median was
  +0.86% and app-server startup was +0.31% relative to fat LTO. ThinLTO
  retains cross-crate optimization while avoiding most of the fat-LTO
  build cost.
  
  This deliberately avoids global size optimization: final-executable
  testing showed a substantial regression on the image request path, which
  is expected to become more important as image usage grows.
  
  ## What changed
  
  - Set the workspace release profile to `lto = "thin"`, retaining Cargo's
  default release `opt-level=3`.
  - Remove release and CI workflow-specific LTO overrides so
  release-profile builds consistently use the workspace setting.
  - Remove the now-unused Windows release workflow input and related
  diagnostic output.
  
  ## Validation
  
  - Confirmed the release profile parses with `cargo metadata --no-deps
  --format-version 1`.
  - CI validates release builds across the supported target matrix.

  Adam Perry @ OpenAI · 2026-06-04 20:07:53 +00:00
  f97d5c3275
• ci: sign macOS release artifacts with Azure Key Vault (#26252)

  ## Why
  
  The public Codex release workflow needs to sign and notarize macOS
  binaries and DMGs without placing the Developer ID private key in
  GitHub. This moves the private-key operation behind the protected
  `codesigning` environment and uses GitHub OIDC with Azure Key Vault
  PKCS#11, while preserving the existing external `build_unsigned` /
  `promote_signed` fallback.
  
  ## What changed
  
  - Add a reusable AKV PKCS11 setup action that authenticates to Azure
  with OIDC, downloads pinned signing tools, verifies their SHA-256
  digests, and loads the public signing certificate from Key Vault.
  - Replace the legacy macOS signing action with scripts that support
  AKV-backed `rcodesign`, notarize signed binaries and DMGs, and staple
  DMG notarization tickets.
  - Restructure `rust-release.yml` so macOS builds produce unsigned
  artifacts first, protected jobs perform signing and notarization, macOS
  runners package and verify the results, and release publishing waits for
  verified artifacts.
  - Preserve the manual external-signing handoff flow and make manual-mode
  conditions explicit.
  - Move the Codex entitlements file alongside the signing scripts and
  update CODEOWNERS for the new signing surfaces.
  
  ## Verification
  
  - [Live protected signing workflow
  run](https://github.com/openai/codex/actions/runs/26903610631) completed
  successfully for both macOS architectures, including binary
  signing/notarization, DMG signing/notarization, and final artifact
  verification.
  - Downloaded both signed DMGs and independently verified their checksums
  and strict signatures.
  - Confirmed `xcrun stapler validate` succeeds and Gatekeeper accepts
  both DMGs as `Notarized Developer ID`.
  - Mounted both DMGs and confirmed the contained `codex` and
  `codex-responses-api-proxy` binaries have valid Developer ID signatures
  for the expected architectures.
  
  ---------
  
  Co-authored-by: shijie-openai <shijie.rao@openai.com>

  Eric Burke · 2026-06-03 20:34:51 -07:00
  ad2012d645
• revert: publish release symbol artifacts (#25988)

  revert https://github.com/openai/codex/pull/25916 and
  https://github.com/openai/codex/pull/25649.

  Shijie Rao · 2026-06-02 17:34:04 -07:00
  d36a3ead3c
• [codex] Publish Python runtime wheels with Python SDK releases (#25906)

  ## Summary
  - stop publishing Python runtime wheels as a side effect of Rust
  releases
  - publish runtime wheels from the Python SDK release workflow, either
  explicitly before updating the SDK pin or immediately before a
  `python-v*` SDK release
  - resolve the runtime release from the requested version or the SDK
  package's exact `openai-codex-cli-bin` pin
  - build two musllinux-tagged wheels from the Rust-release Linux package
  archives alongside the six existing runtime wheels
  - validate SDK beta tags before any PyPI write
  
  ## Release configuration
  - update the `openai-codex-cli-bin` PyPI trusted publisher to trust
  `.github/workflows/python-sdk-release.yml` and the
  `publish-python-runtime` job
  
  ## Pin update flow
  - run the `python-sdk-release` workflow manually with the new runtime
  version before opening or updating the SDK pin PR
  - after the pin lands, a `python-v*` SDK tag republishes with
  `skip-existing: true` before publishing the SDK package
  
  ## Validation
  - ran `just fmt`
  - validated the edited workflow YAML
  - validated the embedded `publish-python-runtime` Bash with `bash -n`
  - validated manual `0.136.0 -> rust-v0.136.0` mapping
  - validated tag-driven `python-v0.1.0b3 -> 0.132.0 -> rust-v0.132.0`
  mapping
  - validated rejection of an invalid SDK tag before publication
  - confirmed `rust-v0.136.0` contains the two required Linux package
  archives
  - CI will provide the full test signal

  Ahmed Ibrahim · 2026-06-02 15:41:53 -07:00
  34dc08c214
• Revert "Use environment secrets for Azure signing" (#25948)

  Reverts openai/codex#24859

  Shijie Rao · 2026-06-02 15:12:07 -07:00
  f752b25fc4
• Use environment secrets for Azure signing (#24859)

  ## Summary
  - Move Azure Trusted Signing values out of reusable workflow-call
  secrets and into the `azure-artifact-signing` environment scope
  - Attach the Windows signing job to the `azure-artifact-signing`
  environment so it can resolve the signing secrets directly
  - Stop inheriting caller secrets for the Windows release reusable
  workflow
  
  ## Validation
  - `git diff --check -- .github/workflows/rust-release.yml
  .github/workflows/rust-release-windows.yml`
  - `ruby -e 'require "yaml"; ARGV.each { |path| YAML.load_file(path);
  puts "ok #{path}" }' .github/workflows/rust-release.yml
  .github/workflows/rust-release-windows.yml`

  Shijie Rao · 2026-06-02 12:41:13 -07:00
  af18e92140
• [codex] Publish release symbol artifacts (#25649)

  ## Why
  
  Production Codex binaries are stripped for distribution, which leaves
  crashes and samples from released builds without the symbols needed for
  useful stack traces. Publish symbols as separate release assets so
  production artifacts stay small while released builds remain
  symbolicateable.
  
  ## What changed
  
  - Add `.github/scripts/archive-release-symbols-and-strip-binaries.sh` to
  package platform-native symbols into `codex-symbols-<artifact>.tar.gz`
  assets while stripping the corresponding Unix binaries before signing.
  - Build release binaries with full debug information before producing
  distribution artifacts.
  - Publish macOS `.dSYM` bundles, Linux `.debug` files with
  `.gnu_debuglink`, and Windows `.pdb` files.
  - Strip Linux `bwrap` before computing its packaged-resource digest, but
  intentionally omit `bwrap` from symbol archives.
  - Preserve symbols artifacts in the unsigned macOS promotion flow.
  
  ## Verification
  
  - Ran `shellcheck` and `bash -n` on
  `.github/scripts/archive-release-symbols-and-strip-binaries.sh`.
  - Parsed the modified workflow YAML files and ran `git diff --check`.
  - Built a macOS release smoke binary and verified that the archived
  `.dSYM` contains DWARF application source information and has the same
  UUID as the stripped production binary.
  - Built Linux smoke binaries and verified that the symbol archive
  contains `codex.debug`, excludes `bwrap.debug`, leaves the expected
  `.gnu_debuglink` in `codex`, and does not mutate the separately stripped
  `bwrap` digest.
  - Staged a Windows smoke archive and verified that it contains the
  expected `.pdb` file.

  Jeremy Rose · 2026-06-01 15:49:54 -07:00
  75a08def98
• [codex] Use git CLI for release Cargo fetches (#25644)

  ## Summary
  - Configure the rust-release build job with
  `CARGO_NET_GIT_FETCH_WITH_CLI=true`
  - Document the macOS SecureTransport/libgit2 failure mode that hit the
  `libwebrtc`/`libyuv` git submodule fetch
  
  ## Root cause
  The release run at
  https://github.com/openai/codex/actions/runs/26717498860/job/78745156683
  repeatedly failed before compilation because Cargo's libgit2 fetch path
  could not clone the nested `yuv-sys/libyuv` submodule from
  `chromium.googlesource.com`, ending with `SecureTransport error:
  connection closed via error`.
  
  ## Validation
  - `git diff --check`
  
  This is a workflow-only change, so I did not run Rust package tests.

  Shijie Rao · 2026-06-01 10:34:12 -07:00
  795031621d
• Disable SQLite intrinsics for Windows x64 releases (#25490)

  ## Why
  
  Codex 0.135.0 started shipping bundled SQLite 3.51.x via SQLx 0.9.0 to
  avoid the older WAL corruption bug fixed by #24728. On Windows x64,
  #25367 reports an immediate `STATUS_ILLEGAL_INSTRUCTION` crash on a
  Haswell CPU when starting normal Codex paths.
  
  Rather than downgrading SQLite, this keeps the newer bundled SQLite
  source and removes SQLite compiler-intrinsic code paths from the Windows
  x64 release build.
  
  ## What changed
  
  For `x86_64-pc-windows-msvc` release builds, export
  `LIBSQLITE3_FLAGS=SQLITE_DISABLE_INTRINSIC` before `cargo build` in:
  
  - `.github/workflows/rust-release.yml`
  - `.github/workflows/rust-release-windows.yml`
  
  Other targets keep their current SQLite build flags.
  
  ## Verification
  
  - `git diff --check`

  Eric Traut · 2026-06-01 09:49:55 -07:00
  8b759b9c18
• Revert "Add build_unsigned_archive release mode" (#25462)

  Reverts openai/codex#25435

  Shijie Rao · 2026-05-31 16:05:33 -07:00
  3b7334d099
• Add build_unsigned_archive release mode (#25435)

  ## Why
  We want a manual mode that produces the full packaged unsigned macOS
  Codex archive, including bundled resources like `rg`, without mixing
  those archives into the signing and publishing flow.
  
  The existing `build_unsigned` mode is the handoff used by external
  signing and `promote_signed`, so archive-only inspection and local
  packaging should live in a separate mode and artifact namespace.
  
  ## What Changed
  - added `build_unsigned_archive` as a new manual `release_mode`
  - kept the existing `build` matrix running for that mode instead of
  introducing a separate archive-only job
  - wrote unsigned macOS package archives to
  `codex-rs/unsigned-archive-dist/...` instead of the normal `dist/...`
  tree
  - uploaded those packaged macOS outputs as dedicated
  `*-unsigned-archive` workflow artifacts
  - kept `build_unsigned` and `promote_signed` on their existing raw
  unsigned binary path
  
  ## Validation
  - parsed `.github/workflows/rust-release.yml` with `ruby -e 'require
  "yaml"; YAML.load_file(".github/workflows/rust-release.yml")'`
  - ran `git diff --check -- .github/workflows/rust-release.yml`
  - reviewed the workflow diff to confirm `build_unsigned_archive` now
  reuses the existing `build` job while isolating the unsigned macOS
  package archives under dedicated artifact names
  - locally verified the package builder layout against unsigned macOS
  binaries to confirm the packaged archive contains `bin/codex`,
  `codex-path/rg`, and `codex-resources/zsh/bin/zsh`

  Shijie Rao · 2026-05-31 14:56:06 -07:00
  5f60b01352
• Remove libubsan CI workaround (#24782)

  It seems that this was added to allow rustc to load proc macros that had
  been compiled with UBSan enabled, which zig does for debug and
  `ReleaseSafe` builds. When zig drives the link of the final binary it
  knows to include the ubsan runtime, but our zig-built artifacts are
  being linked into a binary whose linking rustc drives. This removes the
  libubsan workaround we have and replaces it with
  `-fno-sanitize=undefined` passed to zig.
  
  The new argument is passed at the end of zig's args so should take
  precedence over any earlier arguments from the script's caller.

  Adam Perry @ OpenAI · 2026-05-28 15:49:01 +00:00
  a061befb46
• make vercel webhook url an env secret (#24778)

  move `DEV_WEBSITE_VERCEL_DEPLOY_HOOK_URL` to a repo environment secret.
  
  to keep scope of use of that env secret small, move the vercel website
  redeploy to its own post-release job.

  sayan-oai · 2026-05-27 10:00:05 -07:00
  155905cf72
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• ci: Use codex produced v8 artifacts for release builds (#23934)

  Updates our build script to pull down the artifacts like we do in CI for
  building v8 into our targets.
  
  This changes the flow so that we now pre-install rusty v8 assets for all
  of our release targets from pre-built in workflow.
  Secondarily if running it locally we now optionally pull the assets down
  on python run assuming the user hasn't set the proper values, it then
  provides them.
  
  Sorry for the miss here.

  Channing Conger · 2026-05-22 09:42:08 -07:00
  014f19af5f
• sdk: launch packaged Codex runtimes (#23786)

  ## Why
  
  The Python and TypeScript SDKs launch the native Codex runtime directly,
  so they need to consume the same package artifact shape that release
  jobs now produce. The runtime wheel should be built from the canonical
  Codex package archive rather than reconstructing a parallel layout from
  loose binaries.
  
  ## What Changed
  
  - Stage `openai-codex-cli-bin` by extracting
  `codex-package-<target>.tar.gz` into `src/codex_cli_bin` and validating
  the expected package layout.
  - Update release workflows to pass the generated package archive into
  `stage-runtime` instead of the temporary package directory.
  - Update Python runtime setup to download `codex-package-*.tar.gz`
  release assets directly.
  - Expose Python runtime helpers for the bundled package directory and
  `codex-path`, and prepend that path when `openai_codex` launches the
  installed runtime without duplicating Windows `Path`/`PATH` keys.
  - Teach the TypeScript SDK to resolve package-layout optional
  dependencies while keeping the existing npm fallback layout, and
  preserve the existing Windows path variable casing when prepending
  `codex-path`.
  
  ## Test Plan
  
  - `python3 -m py_compile sdk/python/scripts/update_sdk_artifacts.py
  sdk/python/_runtime_setup.py sdk/python/src/openai_codex/client.py
  sdk/python-runtime/src/codex_cli_bin/__init__.py`
  - `uv run --frozen --project sdk/python --extra dev ruff check
  sdk/python/scripts/update_sdk_artifacts.py sdk/python/_runtime_setup.py
  sdk/python/src/openai_codex/client.py
  sdk/python/tests/test_artifact_workflow_and_binaries.py
  sdk/python-runtime/src/codex_cli_bin/__init__.py`
  - `uv run --frozen --project sdk/python --extra dev pytest
  sdk/python/tests/test_artifact_workflow_and_binaries.py`
  - `pnpm eslint src/exec.ts tests/exec.test.ts`
  - `pnpm test --runInBand tests/exec.test.ts`

  Michael Bolin · 2026-05-20 18:01:22 -07:00
  0b4f86095c
• release: package prebuilt resource binaries (#23759)

  ## Why
  
  Release packaging should be a staging step once release binaries have
  already been built and signed. The Windows release job was downloading
  and signing `codex-command-runner.exe` and
  `codex-windows-sandbox-setup.exe`, but `scripts/build_codex_package.py`
  still rebuilt those helpers while creating the package archives.
  
  That makes the package step slower and, more importantly, risks putting
  helper binaries in the archive that were produced after the signing
  step. Linux had the same shape for package resources: `bwrap` could be
  rebuilt by the package builder instead of being passed in as a prebuilt
  release artifact.
  
  This builds on #23752, which fixes `.tar.zst` creation when Windows
  runners rely on the repository DotSlash `zstd` wrapper.
  
  ## What changed
  
  - Add explicit prebuilt resource inputs to the Codex package builder:
    - `--bwrap-bin`
    - `--codex-command-runner-bin`
    - `--codex-windows-sandbox-setup-bin`
  - Make `.github/scripts/build-codex-package-archive.sh` pass resource
  binaries from the release output directory when they are already
  present.
  - Build Linux `bwrap` for app-server release jobs too, so app-server
  package creation does not invoke Cargo just to supply the package
  resource.
  - Keep macOS package creation as a no-Cargo path when `--entrypoint-bin`
  is provided, since macOS packages have no resource binaries.
  - Add unit coverage showing prebuilt macOS, Linux, and Windows package
  inputs result in no source-built binaries.
  
  ## Verification
  
  - `python3 -m unittest discover -s scripts/codex_package -p 'test_*.py'`
  - `python3 -m py_compile scripts/codex_package/*.py`
  - `bash -n .github/scripts/build-codex-package-archive.sh`
  - Dry-ran Linux and Windows package builds with fake prebuilt resources
  and a nonexistent Cargo path to verify the package builder did not
  invoke Cargo.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23759).
  * #23760
  * __->__ #23759

  Michael Bolin · 2026-05-20 14:51:46 -07:00
  80c4a978f8
• chore: use Codex Linux runners for Rust releases (#23761)

  ## Why
  
  Linux release jobs build the MUSL artifacts that ship in Codex releases,
  including both the primary CLI bundle and the app-server bundle. Those
  builds should run on the Codex Linux runner pools instead of generic
  Ubuntu-hosted runners so release builds use the x64 and arm64 capacity
  intended for Codex artifacts.
  
  ## What Changed
  
  - Moves the `x86_64-unknown-linux-musl` release matrix entries in
  `.github/workflows/rust-release.yml` from `ubuntu-24.04` to
  `codex-linux-x64-xl`.
  - Moves the `aarch64-unknown-linux-musl` release matrix entries from
  `ubuntu-24.04-arm` to `codex-linux-arm64`.
  - Leaves macOS release jobs, target triples, bundle names, and artifact
  names unchanged.
  
  ## Verification
  
  - Reviewed the workflow matrix diff for
  `.github/workflows/rust-release.yml`.
  - Not run locally; this is a GitHub Actions runner configuration change.

  Michael Bolin · 2026-05-20 14:45:19 -07:00
  96aa389c79
• npm: ship platform packages in Codex package layout (#23637)

  ## Summary
  
  The npm platform packages should stop carrying a bespoke native layout
  now that the release workflow builds canonical Codex package archives.
  Keeping npm on the same `bin/`, `codex-resources/`, and `codex-path/`
  structure lets the Rust package-layout detection behave consistently
  across standalone, npm, and future DotSlash installs.
  
  This changes platform npm packages to stage the `codex-package` artifact
  for each target under `vendor/<target>`. The Node launcher now resolves
  `bin/codex` and prepends `codex-path`, while retaining legacy
  `vendor/<target>/codex` and `vendor/<target>/path` fallback support for
  local development and migration. The npm staging helper downloads
  `codex-package` archives instead of rebuilding the CLI payload from
  individual `codex`, `rg`, `bwrap`, and sandbox helper artifacts.
  
  CI still needs to stage npm packages from historical rust-release
  workflow artifacts that predate package archives, so the staging scripts
  expose an explicit `--allow-legacy-codex-package` fallback. That
  fallback synthesizes the canonical package layout from legacy per-binary
  artifacts and is wired only into the CI smoke path; release staging
  remains strict and continues to require real package archives.
  
  For direct local use, `install_native_deps.py` now points its built-in
  default workflow at the same recent artifact run used by CI and
  automatically enables legacy package synthesis only when
  `--workflow-url` is omitted. Explicit workflow URLs remain strict unless
  callers opt in with `--allow-legacy-codex-package`.
  
  ## Test plan
  
  - `python3 -m py_compile codex-cli/scripts/build_npm_package.py
  codex-cli/scripts/install_native_deps.py scripts/stage_npm_packages.py
  scripts/codex_package/cli.py`
  - `node --check codex-cli/bin/codex.js`
  - `ruby -e 'require "yaml";
  YAML.load_file(".github/workflows/rust-release.yml");
  YAML.load_file(".github/workflows/ci.yml"); puts "ok"'`
  - Staged a synthetic `codex-linux-x64` platform package from a canonical
  vendor tree and verified it copied only `bin/`, `codex-path/`,
  `codex-resources/`, and `codex-package.json`.
  - Imported `install_native_deps.py` and extracted a synthetic
  `codex-package-x86_64-unknown-linux-musl.tar.gz` into `vendor/<target>`.
  - Ran legacy-layout conversion smokes for Linux, Windows, and unsigned
  macOS artifact naming.
  - Ran a synthetic `install_native_deps.py` default-workflow smoke that
  verifies legacy package synthesis is automatic only when
  `--workflow-url` is omitted.
  - `NPM_CONFIG_CACHE="$tmp_dir/npm-cache" python3
  ./scripts/stage_npm_packages.py --release-version 0.125.0 --workflow-url
  https://github.com/openai/codex/actions/runs/26131514935 --package codex
  --allow-legacy-codex-package --output-dir "$tmp_dir"`
  - `node codex-cli/bin/codex.js --version`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23637).
  * #23638
  * __->__ #23637

  Michael Bolin · 2026-05-20 12:02:32 -07:00
  e389e01f83
• release: publish Codex package archive checksums (#23635)

  ## Summary
  
  Standalone installers and other downstream package consumers need a
  stable checksum source for the canonical package archives. Relying on
  per-asset metadata makes that harder to consume uniformly, especially
  when several package archives are produced in the same release.
  
  This keeps the `codex-package-*.tar.gz` and
  `codex-app-server-package-*.tar.gz` assets in the GitHub Release upload
  set and adds `codex-package_SHA256SUMS` to `dist/` before the release is
  created. The manifest contains one SHA-256 line per package archive and
  fails the release job if no package archives are present.
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23635).
  * #23638
  * #23637
  * #23636
  * __->__ #23635

  Michael Bolin · 2026-05-20 08:48:04 -07:00
  e9f59e30d9
• ci: build Codex package archives in release workflow (#23582)

  ## Why
  
  Release CI already builds the Codex entrypoints before staging
  artifacts, and the package builder can now package those prebuilt
  binaries directly. The workflow should produce package-shaped sidecar
  archives from the same staged entrypoints that downstream distribution
  channels will eventually consume, without rebuilding `codex` or
  `codex-app-server` inside the packaging step.
  
  This intentionally does **not** publish the new package archives as
  GitHub Release assets yet. The archives are kept with workflow artifacts
  until npm, Homebrew, `install.sh`, winget, and related consumers are
  ready to switch over.
  
  ## What changed
  
  - Adds a `Build Codex package archive` step to
  `.github/workflows/rust-release.yml` after target artifacts are staged.
  - Runs `scripts/build_codex_package.py` for both release bundles:
  - `primary` builds `codex-package-${TARGET}.tar.gz` with `--variant
  codex`.
  - `app-server` builds `codex-app-server-package-${TARGET}.tar.gz` with
  `--variant codex-app-server`.
  - Passes `--entrypoint-bin target/${TARGET}/release/<entrypoint>` so
  packages contain the entrypoint already built by the workflow.
  - Deletes both package archive names before the final GitHub Release
  upload so they remain workflow artifacts only for now.
  
  ## Verification
  
  - Parsed `.github/workflows/rust-release.yml` with Ruby's YAML loader.
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23582).
  * #23596
  * __->__ #23582

  Michael Bolin · 2026-05-20 05:43:53 +00:00
  57a68fb9e3
• Publish Linux runtime wheels with glibc-compatible tags (#21812)

  ## Why
  
  The Python SDK depends on `openai-codex-cli-bin` runtime wheels being
  installable on the Linux hosts our users actually run. The release
  workflow currently tags the Linux runtime artifacts as `musllinux_*`,
  which makes pip ignore them on normal glibc distributions even though
  the bundled Rust executables are intended to run there.
  
  ## What changed
  
  - Tag the Linux runtime wheels as `manylinux_2_17_aarch64` and
  `manylinux_2_17_x86_64` instead of `musllinux_1_1_*`.
  - Keep the existing runtime wheel build and publish flow unchanged
  otherwise.
  
  ## Verification
  
  - Confirmed the wheel-tag issue against the PyPA platform-tag rules for
  `manylinux` vs `musllinux`.
  - This PR is now intentionally scoped to the tag correction only; the
  broader Python runtime release workflow has already landed on `main`
  through the merged stack.
  
  ## Follow-up
  
  After publishing the next alpha from this branch, install the
  SDK/runtime in a fresh glibc Linux environment and confirm pip resolves
  the tagged Linux wheel as expected.
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-18 14:09:25 -07:00
  c95a70fb42
• Disable DMG staging for signed macOS promotion (#22900)

  ## Why
  `promote_signed` is now used to finish a release from an externally
  signed macOS handoff, but this release path (temporarily) no longer
  distributes DMGs. Keeping DMG staging enabled made the handoff
  unnecessarily require DMG assets and notarization/stapling validation
  even though the promoted release only needs the signed macOS binaries.
  
  ## What changed
  - Set every `stage-signed-macos` matrix entry to `build_dmg: "false"`,
  including the primary macOS bundles.
  - Kept the existing DMG staging branch in place behind
  `matrix.build_dmg` so it can be re-enabled deliberately later.
  - Updated the workflow header comment so the signed handoff contract
  asks for signed binaries, not signed DMGs.
  
  The regular signed build path that creates, signs, notarizes, and stages
  DMGs is unchanged; this only affects the `promote_signed` handoff path.

  Shijie Rao · 2026-05-15 14:19:06 -07:00
  98129fb9c5
• Fix signed macOS release promotion follow-up jobs (#22788)

  ## Why
  
  The `release_mode=promote_signed` path intentionally skips the build
  jobs after signed macOS artifacts are staged, then runs the `release`
  job from the signed handoff. In the `rust-v0.131.0-alpha.19` promotion
  run, `release` succeeded but the npm, PyPI, and `latest-alpha-cli`
  follow-up jobs were skipped because their custom job `if:` expressions
  let GitHub Actions apply the implicit `success()` status check before
  reading `needs.release.outputs.*`.
  
  The unsigned build handoff does not need DotSlash manifests. Publishing
  unsigned DotSlash manifests creates release assets that can conflict
  with the later signed promotion, especially shared outputs such as
  `bwrap`, `codex-command-runner`, and `codex-windows-sandbox-setup`.
  
  ## What Changed
  
  - Stop publishing DotSlash manifests when `SIGN_MACOS == 'false'`.
  - Delete `.github/dotslash-unsigned-config.json`.
  - Gate post-release jobs with the `!cancelled()` status function plus an
  explicit `needs.release.result == 'success'` check before consulting
  release outputs.
  - Keep the existing publish eligibility rules for npm, PyPI, WinGet, and
  `latest-alpha-cli`.
  
  ## Verification
  
  - `rg -n "dotslash-unsigned-config|SIGN_MACOS ==
  'false'.*dotslash|unsigned-config" .github/workflows/rust-release.yml
  .github || true`
  - `git diff --check -- .github/workflows/rust-release.yml
  .github/dotslash-unsigned-config.json`

  Shijie Rao · 2026-05-15 00:43:23 -07:00
  302149d979
• ci: support signed macOS release promotion (#22737)

  ## Why
  
  `rust-release.yml` can create unsigned macOS artifacts for external
  signing, but there was no signed resume path after those artifacts
  returned from a secure enclave. Release operators need a way to reuse
  the first run artifacts, ingest signed macOS binaries and DMGs, and
  continue the normal signed release path without rebuilding every
  platform or treating handoff assets as final release assets.
  
  ## How this is meant to be used
  
  First, start the release as an unsigned macOS build against the release
  tag:
  
  ```shell
  gh workflow run rust-release.yml \
    --repo openai/codex \
    --ref rust-vX.Y.Z \
    -f release_mode=build_unsigned
  ```
  
  That run builds the normal Linux/Windows artifacts and publishes
  unsigned macOS handoff artifacts. The unsigned macOS binaries are then
  copied to the secure enclave, signed and notarized there, packaged as a
  signed handoff archive, and uploaded back to the GitHub Release for the
  same tag.
  
  The signed handoff asset should contain either target directories such
  as `aarch64-apple-darwin/` and `x86_64-apple-darwin/`, or artifact
  directories such as `aarch64-apple-darwin-app-server/`. The promote
  workflow accepts either layout. The directories should contain the
  signed binaries and, for primary macOS bundles, the signed and stapled
  DMGs.
  
  For example, after signing, upload the handoff asset to the release:
  
  ```shell
  gh release upload rust-vX.Y.Z \
    signed-macos-rust-vX.Y.Z.tar.zst \
    --repo openai/codex \
    --clobber
  ```
  
  Then start the promotion run. `unsigned_run_id` is the workflow run id
  from the first `build_unsigned` run, and `signed_macos_asset` is the
  exact Release asset name uploaded by the secure enclave:
  
  ```shell
  gh workflow run rust-release.yml \
    --repo openai/codex \
    --ref rust-vX.Y.Z \
    -f release_mode=promote_signed \
    -f unsigned_run_id=1234567890 \
    -f signed_macos_asset=signed-macos-rust-vX.Y.Z.tar.zst \
    -f signed_macos_sha256=<sha256>
  ```
  
  The `signed_macos_sha256` input is optional, but when provided the
  promotion run verifies the handoff archive before unpacking it. The
  promotion run also validates that `unsigned_run_id` points to a
  successful manual `rust-release` run for the same tag and commit before
  importing artifacts.
  
  ## What Changed
  
  - Add explicit manual `release_mode` values for `build_unsigned` and
  `promote_signed` while keeping `sign_macos` as a deprecated
  compatibility input.
  - Add promote inputs for `unsigned_run_id`, `signed_macos_asset`, and
  optional `signed_macos_sha256`.
  - Add a `stage-signed-macos` job that downloads the signed handoff asset
  from the GitHub Release, verifies signed binaries and stapled DMGs,
  repacks normal macOS release artifacts, and builds macOS Python runtime
  wheels.
  - Teach the release job to download Part 1 artifacts from the unsigned
  run, discard unsigned macOS staging artifacts, re-upload promoted Linux
  and Windows artifacts for npm staging, and then run the signed release
  tail.
  - Validate that `unsigned_run_id` points to a successful manual
  `rust-release` run for the same tag and commit before importing
  artifacts.
  - Limit unsigned macOS artifact upload to the unsigned build path so
  normal signed releases do not publish unsigned handoff binaries.
  - Clean up unsigned and signed handoff release assets after successful
  promotion.
  
  ## Verification
  
  - Parsed `.github/workflows/rust-release.yml` with Ruby YAML loading.
  
  No developers.openai.com documentation update is needed.

  Michael Bolin · 2026-05-14 18:36:20 -07:00
  db51df0f44
• Chore: better published unsigned artifacts (#22649)

  This is the exact same change as @bolinfest made but he could not push
  because of github action change permission.
  
  ## Why
  
  The `rust-release` workflow can now be run manually with
  `sign_macos=false` to skip macOS signing, but that path previously
  stopped before creating a GitHub Release. That left the unsigned macOS
  binaries available only as workflow-run artifacts, which are awkward to
  fetch from automation and cannot be retrieved with a simple
  unauthenticated `curl`.
  
  For the unsigned path we still should not perform the normal release
  side effects: no npm or Python publishing, no WinGet publishing, no
  `latest-alpha-cli` branch update, and no promotion to GitHub's latest
  release. The goal is only to make the build outputs easy to fetch from
  the release page.
  
  ## What changed
  
  - Allow the `release` job in `.github/workflows/rust-release.yml` to run
  for `workflow_dispatch` runs with `sign_macos=false`.
  - For unsigned runs, keep the unsigned macOS artifacts plus the normal
  Linux and Windows release artifacts needed for DotSlash, then
  create/update the GitHub Release with `make_latest: false`.
  - Keep the normal publish/promote paths gated to signed releases:
    - npm staging and publish
    - Python runtime publish
    - WinGet publish
    - `latest-alpha-cli` update
    - developer-site deploy
    - normal DotSlash release files
  - Add `.github/dotslash-unsigned-config.json`, which publishes
  `*-unsigned` DotSlash files that use unsigned macOS artifacts and the
  normal Linux/Windows artifacts.
  
  
  ## What I added
  PLEASE READ THIS!!!
  I added `codex-command-runner` and `codex-windows-sandbox-setup` entries
  to `.github/dotslash-unsigned-config.json` so that with
  `sign_macos=false` we would still get the dotslash files for those
  artifacts which are necessary for windows builds.

  Shijie Rao · 2026-05-14 08:47:21 -07:00
  e79e1b42b9
• Add unsigned macOS release artifacts (#22559)

  ## Summary
  - Upload unsigned macOS release binaries before signing so they remain
  available from the workflow run if signing fails
  - Add a manual `workflow_dispatch` option, `sign_macos`, defaulting to
  `true`
  - When `sign_macos=false`, skip macOS signing, signed-name macOS
  artifacts, DMGs, npm/DotSlash/PyPI publishing, latest release marking,
  and `latest-alpha-cli` updates
  
  
  ## Process
  HAVE NOT TESTED YET BUT we should be able to run
  ```
  gh workflow run rust-release.yml \
    -R openai/codex \
    --ref rust-v0.132.0 \
    -f sign_macos=false
  ```
  
  which will then start the rust-release script with `sign_macos` and
  therefore do not codesign mac and also no release afterward.

  Shijie Rao · 2026-05-13 16:47:44 -07:00
  49d1f66c4c
• Revert "Scope macOS signing secrets to release environment" (#22513)

  Reverts openai/codex#22443

  Shijie Rao · 2026-05-13 10:41:45 -07:00
  157fffc6a4
• Scope macOS signing secrets to release environment (#22443)

  ## Summary
  - Split macOS Rust release builds into a dedicated `build-macos` job
  - Attach the `macos-signing` environment only to the macOS signing/build
  job
  - Keep Linux release builds outside the Apple signing environment while
  preserving the existing shared release build steps

  Shijie Rao · 2026-05-13 06:31:08 -07:00
  99157f3797
• [1/8] Pin Python SDK runtime dependency (#21891)

  ## Why
  
  The Python SDK depends on the app-server runtime package for the bundled
  `codex` binary and schema source of truth. That relationship should be
  explicit in package metadata instead of inferred from matching version
  numbers, so installers, lockfiles, and reviewers can see exactly which
  runtime the SDK expects.
  
  ## What
  
  - Declare `openai-codex-cli-bin==0.131.0a4` as a Python SDK dependency.
  - Update runtime setup helpers to resolve the runtime version from the
  declared dependency pin.
  - Refresh the SDK lockfile for the pinned runtime wheel.
  - Update package/runtime tests and docs that describe where the runtime
  version comes from.
  
  ## Stack
  
  1. This PR `[1/8]` Pin Python SDK runtime dependency
  2. #21893 `[2/8]` Generate Python SDK types from pinned runtime
  3. #21895 `[3/8]` Run Python SDK tests in CI
  4. #21896 `[4/8]` Define Python SDK public API surface
  5. #21905 `[5/8]` Rename Python SDK package to `openai-codex`
  6. #21910 `[6/8]` Add high-level Python SDK approval mode
  7. #22014 `[7/8]` Add Python SDK app-server integration harness
  8. #22021 `[8/8]` Add Python SDK Ruff formatting
  
  ## Verification
  
  - Added coverage for the SDK runtime dependency pin and runtime
  distribution naming.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-12 00:42:26 +03:00
  5fe33443b0
• Revert "Publish Python runtime wheels on release" (#21810)

  Reverts openai/codex#21784

  Ahmed Ibrahim · 2026-05-08 22:37:10 +03:00
  cf941ede15
• Publish Python runtime wheels on release (#21784)

  ## Why
  
  Published Python SDK builds depend on an exact `openai-codex-cli-bin`
  runtime package, but the release workflow did not publish that runtime
  package to PyPI. That left the SDK packaging story incomplete: release
  artifacts could produce Codex binaries, but Python users still needed a
  matching wheel carrying the platform-specific runtime and helper
  executables.
  
  This PR is stacked on #21787 so release jobs can include helper binaries
  in runtime wheels: Linux wheels include `bwrap` for sandbox fallback,
  and Windows wheels include the signed sandbox/elevation helpers beside
  `codex.exe`.
  
  ## What changed
  
  - Builds platform-specific `openai-codex-cli-bin` wheels from signed
  release binaries on macOS, Linux, and Windows release runners.
  - Packages Linux `bwrap` into musllinux runtime wheels.
  - Packages Windows sandbox helper executables into Windows runtime
  wheels.
  - Uploads runtime wheels as GitHub release assets and publishes them to
  PyPI using trusted publishing from the `pypi` GitHub environment.
  - Keeps the new Python runtime publish job non-blocking so failures need
  follow-up but do not fail the Rust release workflow.
  - Pins the PyPA publish action to the `v1.13.0` commit SHA for
  reproducible release publishing.
  - Documents that runtime wheels are platform wheels published through
  PyPI trusted publishing.
  
  ## Testing
  
  - `ruby -e 'require "yaml"; ARGV.each { |f| YAML.load_file(f); puts "ok
  #{f}" }' .github/workflows/rust-release.yml
  .github/workflows/rust-release-windows.yml`
  - `git diff --check`
  
  CI is the real end-to-end verification for the release workflow path.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 22:00:58 +03:00
  9183503b97
• [codex] Address some more GHA hygiene issues (#21622)

  This does two things:
  
  - We use `persist-credentials: false` everywhere now. This is
  unfortunately not the default in GitHub Actions, but it prevents
  `actions/checkout` from dropping `secrets.GITHUB_TOKEN` onto disk.
  - We interpose (some) template expansions through environment variables.
  I've limited this to contexts that have non-fixed values; contexts that
  are fixed (like `*.result`) are not dangerous to expand directly inline
  (but maybe we should clean those up in the future for consistency
  anyways).
  
  This is a medium-risk change in terms of CI breakage: I did a scan for
  usage of `git push` and other commands that implicitly use the persisted
  credential, but couldn't find any. Even still, some implicit usages of
  the persisted credentials may be lurking. Please ping ww@ if any issues
  arise.

  William Woodruff · 2026-05-08 10:19:27 -07:00
  8bea5d231a
• Revert "Use --locked in cargo build and lint invocations" (#21646)

  Reverts openai/codex#21602

  pakrym-oai · 2026-05-07 20:05:47 -07:00
  af16baa549
• Use --locked in cargo build and lint invocations (#21602)

  This ensures CI fails if the committed lockfile is outdated

  Zanie Blue · 2026-05-07 23:14:18 +00:00
  79154e6952
• [codex] Fully qualify hash-pins in GitHub Actions (#21436)

  This builds on top of https://github.com/openai/codex/pull/15828 by
  ensuring that hash-pinned actions with version comments are fully
  qualified, rather than referencing floating/mutable comments like "v7".
  This makes actions management tools behave more consistently.
  
  This shouldn't break anything, since it's comment only. But if it does,
  ping ww@ 🙂

  William Woodruff · 2026-05-07 14:31:20 -07:00
  8abcc5357d
• release: bundle bwrap with Linux codex DotSlash artifact (#21312)

  ## Why
  
  #21255 changed the Linux sandbox fallback so Codex can use a bundled
  `codex-resources/bwrap` executable when no suitable system `bwrap` is
  available. That lookup is relative to the native Codex executable
  returned by
  `std::env::current_exe()`, as implemented in
  [`bundled_bwrap.rs`](https://github.com/openai/codex/blob/9766d3d51cec885114b6d6c53a02e9efbaf87171/codex-rs/linux-sandbox/src/bundled_bwrap.rs#L83-L93).
  
  The release already publishes a separate `bwrap` DotSlash output, but
  the Linux `codex` DotSlash output still pointed at a single-binary
  `.zst` payload. Running the `codex` DotSlash manifest only materializes
  the native `codex` executable; it does not also create sibling files
  from the separate `bwrap` manifest. The fallback path therefore needs
  the Linux `codex` DotSlash artifact itself to include the real `bwrap`
  executable at `codex-resources/bwrap`.
  
  ## What changed
  
  - stage a Linux primary `codex-<target>-bundle.tar.zst` release artifact
  containing `codex` and `codex-resources/bwrap`
  - point the Linux `codex` DotSlash outputs at that bundle tarball
  - leave the standalone `bwrap` DotSlash output in place for consumers
  that want to fetch `bwrap` directly
  
  ## Verification
  
  - `jq . .github/dotslash-config.json`
  - Ruby YAML parse of `.github/workflows/rust-release.yml`

  Michael Bolin · 2026-05-05 23:33:13 -07:00
  22326e263c
• release/npm: bundle standalone bwrap on Linux (#21257)
  Michael Bolin · 2026-05-05 18:21:52 -07:00
  a736cb55a2
• release: publish standalone bwrap artifacts (#21256)

  **Summary**
  - Build Linux `bwrap` before the main release binaries.
  - Export the release `bwrap` SHA-256 as `CODEX_BWRAP_SHA256` so the
  Codex binary can verify the bundled fallback.
  - Sign, stage, and upload `bwrap` alongside the primary Linux release
  artifacts.
  
  **Verification**
  - YAML parse check for `.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/21256).
  * #21257
  * __->__ #21256

  Michael Bolin · 2026-05-05 17:15:46 -07:00
  3ec18a2c0a
• fix: cargo deny (#20627)

  Fix cargo deny by ack the `RUSTSEC` while a fix land
  ```
    RUSTSEC-2026-0118
    NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
  
    RUSTSEC-2026-0119
    CPU exhaustion during message encoding due to O(n²) name compression
  
    Dependency path:
  
    hickory-proto 0.25.2
    └── hickory-resolver 0.25.2
        └── rama-dns 0.3.0-alpha.4
            └── rama-tcp 0.3.0-alpha.4
                └── codex-network-proxy
  ```
  
  Also upgrade some workers version to prevent this:
  ```
  warning[license-not-encountered]: license was not encountered
      ┌─ ./codex-rs/deny.toml:131:6
      │
  131 │     "OpenSSL",
      │      ━━━━━━━ unmatched license allowance
  
  warning[duplicate]: found 2 duplicate entries for crate 'base64'
     ┌─ /github/workspace/codex-rs/Cargo.lock:79:1
     │
  79 │ ╭ base64 0.21.7 registry+https://github.com/rust-lang/crates.io-index
  80 │ │ base64 0.22.1 registry+https://github.com/rust-lang/crates.io-index
     │ ╰───────────────────────────────────────────────────────────────────┘ lock entries
  ```

  jif-oai · 2026-05-01 18:15:38 +02:00
  5744b85b9a
• ci: increase Windows release workflow timeouts (#20343)

  ## Why
  
  #20271 increased the `90`-minute timeout in `rust-release.yml`, but it
  did not update the reusable Windows workflow in
  `rust-release-windows.yml`. As a result, the Windows release compile
  jobs were still capped at `60` minutes and the `windows-x64` primary
  build could continue timing out.
  
  We are keeping the existing `90`-minute timeout in `rust-release.yml`.
  That increase was still directionally correct because the top-level
  release build benefits from extra headroom; the mistake was assuming it
  also covered the reusable Windows jobs.
  
  ## What Changed
  - increase the reusable Windows release workflow timeouts in
  `rust-release-windows.yml` from `60` minutes to `90` minutes
  - update the comment in `rust-release.yml` so it no longer implies that
  the top-level timeout covers the Windows reusable jobs

  Michael Bolin · 2026-04-29 23:27:04 -07:00
  ae863e72a2
• chore: increase release build timeout from 60 min to 90 (#20271)

  Build times are creeping up, so increase the timeout as a precaution.

  Michael Bolin · 2026-04-29 16:19:59 -07:00
  6eab7519b4
• Guard npm update readiness (#19389)

  ## Why
  For npm/Bun-managed installs, the update prompt was treating the latest
  GitHub release as ready to install. During the `0.124.0` release, GitHub
  and npm visibility were not atomic: the root npm wrapper could become
  visible before the npm registry marked that version as the package
  `latest`. That left a window where users could be prompted to upgrade
  before npm was ready for the release.
  
  ## What changed
  - Keep GitHub Releases as the candidate latest-version source for
  npm/Bun installs, but only write the existing `version.json` cache after
  npm registry metadata proves that same root version is ready.
  - Add `codex-rs/tui/src/npm_registry.rs` to validate npm readiness by
  checking `dist-tags.latest` and root package `dist` metadata for the
  GitHub candidate version.
  - Move version parsing helpers into
  `codex-rs/tui/src/update_versions.rs` so that logic can be tested
  without compiling the release-only `updates.rs` module under tests.
  - Update `.github/workflows/rust-release.yml` so the six known platform
  tarballs publish before the root `@openai/codex` wrapper. Other npm
  tarballs publish before the root wrapper, and the SDK publishes after
  the root package it depends on.

  Shijie Rao · 2026-04-25 17:09:29 -07:00
  4e30281a13
• ci: publish codex-app-server release artifacts (#19447)

  ## Why
  The VS Code extension and desktop app do not need the full TUI binary,
  and `codex-app-server` is materially smaller than standalone `codex`. We
  still want to publish it as an official release artifact, but building
  it by tacking another `--bin` onto the existing release `cargo build`
  invocations would lengthen those jobs.
  
  This change keeps `codex-app-server` on its own release bundle so it can
  build in parallel with the existing `codex` and helper bundles.
  
  ## What changed
  - Made `.github/workflows/rust-release.yml` bundle-aware so each macOS
  and Linux MUSL target now builds either the existing `primary` bundle
  (`codex` and `codex-responses-api-proxy`) or a standalone `app-server`
  bundle (`codex-app-server`).
  - Preserved the historical artifact names for the primary macOS/Linux
  bundles so `scripts/stage_npm_packages.py` and
  `codex-cli/scripts/install_native_deps.py` continue to find release
  assets under the paths they already expect, while giving the new
  app-server artifacts distinct names.
  - Added a matching `app-server` bundle to
  `.github/workflows/rust-release-windows.yml`, and updated the final
  Windows packaging job to download, sign, stage, and archive
  `codex-app-server.exe` alongside the existing release binaries.
  - Generalized the shared signing actions in
  `.github/actions/linux-code-sign/action.yml`,
  `.github/actions/macos-code-sign/action.yml`, and
  `.github/actions/windows-code-sign/action.yml` so each workflow row
  declares its binaries once and reuses that list for build, signing, and
  staging.
  - Added `codex-app-server` to `.github/dotslash-config.json` so releases
  also publish a generated DotSlash manifest for the standalone app-server
  binary.
  - Kept the macOS DMG focused on the existing `primary` bundle;
  `codex-app-server` ships as the regular standalone archives and DotSlash
  manifest.
  
  ## Verification
  - Parsed the modified workflow and action YAML files locally with
  `python3` + `yaml.safe_load(...)`.
  - Parsed `.github/dotslash-config.json` locally with `python3` +
  `json.loads(...)`.
  - Reviewed the resulting release matrices, artifact names, and packaging
  paths to confirm that `codex-app-server` is built separately on macOS,
  Linux MUSL, and Windows, while the existing npm staging and Windows
  `codex` zip bundling contracts remain intact.

  Michael Bolin · 2026-04-24 15:29:37 -07:00
  9b8a1fbefc
• ci: stop publishing GNU Linux release artifacts (#19445)

  ## Why
  We already prefer shipping the MUSL Linux builds, and the in-repo
  release consumers resolve Linux release assets through the MUSL targets.
  Keeping the GNU release jobs around adds release time and extra assets
  without serving the paths we actually publish and consume.
  
  This is also easier to reason about as a standalone change: future work
  can point back to this PR as the intentional decision to stop publishing
  `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` release
  artifacts.
  
  ## What changed
  - Removed the `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu`
  entries from the `build` matrix in `.github/workflows/rust-release.yml`.
  - Added a short comment in that matrix documenting that Linux release
  artifacts intentionally ship MUSL-linked binaries.
  
  ## Verification
  - Reviewed `.github/workflows/rust-release.yml` to confirm that the
  release workflow now only builds Linux release artifacts for
  `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl`.

  Michael Bolin · 2026-04-24 21:29:45 +00:00
  db94b1657b
• fix: pin inputs (#17471)

  ## Summary
  - Pin Rust git patch dependencies to immutable revisions and make
  cargo-deny reject unknown git and registry sources unless explicitly
  allowlisted.
  - Add checked-in SHA-256 coverage for the current rusty_v8 release
  assets, wire those hashes into Bazel, and verify CI override downloads
  before use.
  - Add rusty_v8 MODULE.bazel update/check tooling plus a Bazel CI guard
  so future V8 bumps cannot drift from the checked-in checksum manifest.
  - Pin release/lint cargo installs and all external GitHub Actions refs
  to immutable inputs.
  
  ## Future V8 bump flow
  Run these after updating the resolved `v8` crate version and checksum
  manifest:
  
  ```bash
  python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
  python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
  ```
  
  The update command rewrites the matching `rusty_v8_<crate_version>`
  `http_file` SHA-256 values in `MODULE.bazel` from
  `third_party/v8/rusty_v8_<crate_version>.sha256`. The check command is
  also wired into Bazel CI to block drift.
  
  ## Notes
  - This intentionally excludes RustSec dependency upgrades and
  bubblewrap-related changes per request.
  - The branch was rebased onto the latest origin/main before opening the
  PR.
  
  ## Validation
  - cargo fetch --locked
  - cargo deny check advisories
  - cargo deny check
  - cargo deny check sources
  - python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
  - python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
  - python3 -m unittest discover -s .github/scripts -p
  'test_rusty_v8_bazel.py'
  - python3 -m py_compile .github/scripts/rusty_v8_bazel.py
  .github/scripts/rusty_v8_module_bazel.py
  .github/scripts/test_rusty_v8_bazel.py
  - repo-wide GitHub Actions `uses:` audit: all external action refs are
  pinned to 40-character SHAs
  - yq eval on touched workflows and local actions
  - git diff --check
  - just bazel-lock-check
  
  ## Hash verification
  - Confirmed `MODULE.bazel` hashes match
  `third_party/v8/rusty_v8_146_4_0.sha256`.
  - Confirmed GitHub release asset digests for denoland/rusty_v8
  `v146.4.0` and openai/codex `rusty-v8-v146.4.0` match the checked-in
  hashes.
  - Streamed and SHA-256 hashed all 10 `MODULE.bazel` rusty_v8 asset URLs
  locally; every downloaded byte stream matched both `MODULE.bazel` and
  the checked-in manifest.
  
  ## Pin verification
  - Confirmed signing-action pins match the peeled commits for their tag
  comments: `sigstore/cosign-installer@v3.7.0`, `azure/login@v2`, and
  `azure/trusted-signing-action@v0`.
  - Pinned the remaining tag-based action refs in Bazel CI/setup:
  `actions/setup-node@v6`, `facebook/install-dotslash@v2`,
  `bazelbuild/setup-bazelisk@v3`, and `actions/cache/restore@v5`.
  - Normalized all `bazelbuild/setup-bazelisk@v3` refs to the peeled
  commit behind the annotated tag.
  - Audited Cargo git dependencies: every manifest git dependency uses
  `rev` only, every `Cargo.lock` git source has `?rev=<sha>#<same-sha>`,
  and `cargo deny check sources` passes with `required-git-spec = "rev"`.
  - Shallow-fetched each distinct git dependency repo at its pinned SHA
  and verified Git reports each object as a commit.

  viyatb-oai · 2026-04-14 01:45:41 +00:00
  d9a385ac8c
• Use Node 24 for npm publish (#16755)

  Avoid self-upgrading the runner's bundled npm in release publishing;
  Node 24 already provides an npm CLI that supports trusted publishing.
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 19:26:41 -07:00
  13d828d236
• [codex] Pin GitHub Actions workflow references (#15828)

  Pin floating external GitHub Actions workflow refs to immutable SHAs.
  
  Why are we doing this? Please see the rationale doc:
  https://docs.google.com/document/d/1qOURCNx2zszQ0uWx7Fj5ERu4jpiYjxLVWBWgKa2wTsA/edit?tab=t.0
  
  Did this break you? Please roll back and let hintz@ know

  Drew Hintz · 2026-03-27 23:00:05 +00:00
  f4f6eca871
• fix: keep zsh-fork release assets after removing shell-tool-mcp (#15644)

  ## Why
  
  `shell-tool-mcp` and the Bash fork are no longer needed, but the patched
  zsh fork is still relevant for shell escalation and for the
  DotSlash-backed zsh-fork integration tests.
  
  Deleting the old `shell-tool-mcp` workflow also deleted the only
  pipeline that rebuilt those patched zsh binaries. This keeps the package
  removal, while preserving a small release path that can be reused
  whenever `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch`
  changes.
  
  ## What changed
  
  - removed the `shell-tool-mcp` workspace package, its npm
  packaging/release jobs, the Bash test fixture, and the remaining
  Bash-specific compatibility wiring
  - deleted the old `.github/workflows/shell-tool-mcp.yml` and
  `.github/workflows/shell-tool-mcp-ci.yml` workflows now that their
  responsibilities have been replaced or removed
  - kept the zsh patch under
  `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch` and updated
  the `codex-rs/shell-escalation` docs/code to describe the zsh-based flow
  directly
  - added `.github/workflows/rust-release-zsh.yml` to build only the three
  zsh binaries that `codex-rs/app-server/tests/suite/zsh` needs today:
    - `aarch64-apple-darwin` on `macos-15`
    - `x86_64-unknown-linux-musl` on `ubuntu-24.04`
    - `aarch64-unknown-linux-musl` on `ubuntu-24.04`
  - extracted the shared zsh build/smoke-test/stage logic into
  `.github/scripts/build-zsh-release-artifact.sh`, made that helper
  directly executable, and now invoke it directly from the workflow so the
  Linux and macOS jobs only keep the OS-specific setup in YAML
  - wired those standalone `codex-zsh-*.tar.gz` assets into
  `rust-release.yml` and added `.github/dotslash-zsh-config.json` so
  releases also publish a `codex-zsh` DotSlash file
  - updated the checked-in `codex-rs/app-server/tests/suite/zsh` fixture
  comments to explain that new releases come from the standalone zsh
  assets, while the checked-in fixture remains pinned to the latest
  historical release until a newer zsh artifact is published
  - tightened a couple of follow-on cleanups in
  `codex-rs/shell-escalation`: the `ExecParams::command` comment now
  describes the shell `-c`/`-lc` string more clearly, and the README now
  points at the same `git.code.sf.net` zsh source URL that the workflow
  uses
  
  ## Testing
  
  - `cargo test -p codex-shell-escalation`
  - `just argument-comment-lint`
  - `bash -n .github/scripts/build-zsh-release-artifact.sh`
  - attempted `cargo test -p codex-core`; unrelated existing failures
  remain, but the touched `tools::runtimes::shell::unix_escalation::*`
  coverage passed during that run

  Michael Bolin · 2026-03-24 12:56:26 -07:00
  e89e5136bd