155 Commits

• 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
• Bump vedantmgoyal9/winget-releaser from 19e706d4c9121098010096f9c495a70a7518b30f to 7bd472be23763def6e16bd06cc8b1cdfab0e2fd5 (#14777)

  Bumps
  [vedantmgoyal9/winget-releaser](https://github.com/vedantmgoyal9/winget-releaser)
  from 19e706d4c9121098010096f9c495a70a7518b30f to
  7bd472be23763def6e16bd06cc8b1cdfab0e2fd5.
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/vedantmgoyal9/winget-releaser/commit/7bd472be23763def6e16bd06cc8b1cdfab0e2fd5"><code>7bd472b</code></a>
  docs: add description to inputs (<a
  href="https://redirect.github.com/vedantmgoyal9/winget-releaser/issues/335">#335</a>)</li>
  <li><a
  href="https://github.com/vedantmgoyal9/winget-releaser/commit/a43926ed822e5a076ac8a81e0a794915cbad51d1"><code>a43926e</code></a>
  fix: cargo command not found in <code>ubuntu-slim</code> runner (<a
  href="https://redirect.github.com/vedantmgoyal9/winget-releaser/issues/334">#334</a>)</li>
  <li>See full diff in <a
  href="https://github.com/vedantmgoyal9/winget-releaser/compare/19e706d4c9121098010096f9c495a70a7518b30f...7bd472be23763def6e16bd06cc8b1cdfab0e2fd5">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2026-03-24 09:42:05 -06:00
  68baac7cf4
• chore(deps): bump pnpm/action-setup from 4 to 5 (#15484)

  Bumps [pnpm/action-setup](https://github.com/pnpm/action-setup) from 4
  to 5.
  <details>
  <summary>Release notes</summary>
  <p><em>Sourced from <a
  href="https://github.com/pnpm/action-setup/releases">pnpm/action-setup's
  releases</a>.</em></p>
  <blockquote>
  <h2>v5.0.0</h2>
  <p>Updated the action to use Node.js 24.</p>
  <h2>v4.4.0</h2>
  <p>Updated the action to use Node.js 24.</p>
  <h2>v4.3.0</h2>
  <h2>What's Changed</h2>
  <ul>
  <li>docs: fix the run_install example in the Readme by <a
  href="https://github.com/dreyks"><code>@​dreyks</code></a> in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/175">pnpm/action-setup#175</a></li>
  <li>chore: remove unused <code>@types/node-fetch</code> dependency by <a
  href="https://github.com/silverwind"><code>@​silverwind</code></a> in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/186">pnpm/action-setup#186</a></li>
  <li>Clarify that package_json_file is relative to GITHUB_WORKSPACE by <a
  href="https://github.com/chris-martin"><code>@​chris-martin</code></a>
  in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/184">pnpm/action-setup#184</a></li>
  <li>feat: store caching by <a
  href="https://github.com/jrmajor"><code>@​jrmajor</code></a> in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/188">pnpm/action-setup#188</a></li>
  <li>refactor: remove star imports by <a
  href="https://github.com/KSXGitHub"><code>@​KSXGitHub</code></a> in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/196">pnpm/action-setup#196</a></li>
  <li>fix(ci): exclude macos by <a
  href="https://github.com/KSXGitHub"><code>@​KSXGitHub</code></a> in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/197">pnpm/action-setup#197</a></li>
  </ul>
  <h2>New Contributors</h2>
  <ul>
  <li><a href="https://github.com/dreyks"><code>@​dreyks</code></a> made
  their first contribution in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/175">pnpm/action-setup#175</a></li>
  <li><a
  href="https://github.com/silverwind"><code>@​silverwind</code></a> made
  their first contribution in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/186">pnpm/action-setup#186</a></li>
  <li><a
  href="https://github.com/chris-martin"><code>@​chris-martin</code></a>
  made their first contribution in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/184">pnpm/action-setup#184</a></li>
  <li><a href="https://github.com/jrmajor"><code>@​jrmajor</code></a> made
  their first contribution in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/188">pnpm/action-setup#188</a></li>
  <li><a
  href="https://github.com/Boosted-Bonobo"><code>@​Boosted-Bonobo</code></a>
  made their first contribution in <a
  href="https://redirect.github.com/pnpm/action-setup/pull/199">pnpm/action-setup#199</a></li>
  </ul>
  <p><strong>Full Changelog</strong>: <a
  href="https://github.com/pnpm/action-setup/compare/v4.2.0...v4.3.0">https://github.com/pnpm/action-setup/compare/v4.2.0...v4.3.0</a></p>
  <h2>v4.2.0</h2>
  <p>When there's a <code>.npmrc</code> file at the root of the
  repository, pnpm will be fetched from the registry that is specified in
  that <code>.npmrc</code> file <a
  href="https://redirect.github.com/pnpm/action-setup/pull/179">#179</a></p>
  <h2>v4.1.0</h2>
  <p>Add support for <code>package.yaml</code> <a
  href="https://redirect.github.com/pnpm/action-setup/pull/156">#156</a>.</p>
  </blockquote>
  </details>
  <details>
  <summary>Commits</summary>
  <ul>
  <li>See full diff in <a
  href="https://github.com/pnpm/action-setup/compare/v4...v5">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=pnpm/action-setup&package-manager=github_actions&previous-version=4&new-version=5)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2026-03-24 09:40:31 -06:00
  d7343486da
• Add v8-poc consumer of our new built v8 (#15203)

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

  Channing Conger · 2026-03-20 12:08:25 -07:00
  1350477150
• Publish runnable DotSlash package for argument-comment lint (#15198)

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

  Michael Bolin · 2026-03-19 18:59:02 +00:00
  b87ba0a3cc
• Pin setup-zig GitHub Action to immutable SHA (#14858)

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

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

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

  Michael Bolin · 2026-03-16 22:01:16 -07:00
  15ede607a0
• Codex/winget auto update (#12943)

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

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

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

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

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

  dependabot[bot] · 2026-03-04 17:40:54 -07:00
  84ba9f8e74
• [release] temporarily use thin LTO for releases (#13506)
  Michael Bolin · 2026-03-04 14:10:54 -08:00
  4907096d13
• Add Windows direct install script (#12741)

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

  EFRAZER-oai · 2026-03-03 09:25:50 -08:00
  168e35b6f2
• Add macOS and Linux direct install script (#12740)

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

  EFRAZER-oai · 2026-02-26 00:33:50 +00:00
  a1cd78c818