176 Commits

• release: consume standalone zsh artifacts (#30116)

  ## Why
  
  Once #30114 publishes zsh independently, regular Rust releases should
  reuse that protected, versioned artifact set instead of rebuilding
  identical zsh binaries for every Codex version. Keeping the zsh release
  tag explicit in the workflow also makes future artifact upgrades
  deliberate and easy to review.
  
  This PR assumes the first standalone artifact release will be published
  as `codex-zsh-v0.1.0` before this change lands.
  
  ## What changed
  
  - Added `CODEX_ZSH_RELEASE_TAG` near the top of
  `.github/workflows/rust-release.yml`, initially pinned to
  `codex-zsh-v0.1.0`.
  - Download the standalone release’s generated `codex-zsh` DotSlash
  manifest before assembling Linux and macOS Codex packages.
  - Added a `--zsh-manifest` package-builder override so release packaging
  fetches the matching target archive and verifies the size and SHA-256
  digest recorded in that manifest.
  - Removed the reusable zsh build job from regular Rust releases.
  - Stopped copying zsh archives into each Rust release and stopped
  regenerating a zsh DotSlash manifest there.
  
  Windows packaging remains unchanged because the patched zsh resource is
  only shipped for supported Unix targets.
  
  ## Testing
  
  - Added package-helper coverage that supplies a standalone manifest
  override and verifies the extracted zsh bytes.
  - Ran the `scripts/codex_package` unit test suite.
  - Validated `.github/scripts/build-codex-package-archive.sh` with `bash
  -n`.

  Michael Bolin · 2026-06-25 14:05:49 -07:00
  e23e7cbe46
• [codex] revert concurrent npm publishing (#27639)

  In https://github.com/openai/codex/actions/runs/27354608310, the
  concurrency introduced by
  
  https://github.com/openai/codex/commit/5e50e7e639c9284ceac24a5498b73a5602fb6615
  caused the npm publish job to fail.
  
  The six platform tarballs contain different versions of the same
  `@openai/codex` package. Every publish updates the same packument, so
  only two concurrent updates succeeded while four failed with HTTP 409.
  
  Serializing that group would leave only the responses API proxy running
  in parallel. Saving one publish does not justify the nested `xargs`
  machinery needed to express those groups.
  
  Restore the serial publish loop and document why the platform variants
  must not publish concurrently. Platform packages remain ahead of the
  root CLI wrapper, and the SDK remains after its exact root dependency.

  Tamir Duberstein · 2026-06-11 18:04:24 +00:00
  b42bff21bb
• [codex] download only release artifacts (#27529)

  In https://github.com/openai/codex/actions/runs/27308011621, the
  release job downloaded 10.0 GiB of workflow artifacts in 87 seconds,
  then discarded 42 artifacts accounting for 3.3 GiB.
  
  Select target and supplemental release artifact patterns at download
  time. This also excludes duplicate Cargo timing files without a cleanup
  pass and should reduce total release time by about 30 seconds.

  Tamir Duberstein · 2026-06-11 10:34:41 -04:00
  f42780109c
• [codex] publish DotSlash alongside npm (#27528)

  In https://github.com/openai/codex/actions/runs/27308011621,
  preparing and publishing the three DotSlash configurations took 72
  seconds after creating the GitHub release. npm publication could not
  start until those independent steps finished.
  
  Move DotSlash publication to a sibling job that starts after the GitHub
  release. npm and DotSlash can then proceed concurrently, reducing total
  release time by about one minute.

  Tamir Duberstein · 2026-06-11 10:23:46 -04:00
  9163c0a335
• [codex] publish npm packages concurrently (#27527)

  In https://github.com/openai/codex/actions/runs/27308011621,
  publishing the npm tarballs serially took 147 seconds. Six platform
  packages and the responses API proxy are independent.
  
  Publish those packages concurrently, then publish the root CLI wrapper
  and SDK in dependency order. Individual platform publishes took 19 to
  23 seconds, so this should reduce total release time by nearly two
  minutes.

  Tamir Duberstein · 2026-06-11 07:19:27 -07:00
  5e50e7e639
• [codex] reuse release artifacts for npm staging (#27312)

  The release job already downloads every workflow artifact into `dist`,
  but npm staging creates a new cache and downloads the six target
  artifacts again.
  
  Reuse `dist` as the staging script's artifact cache while preserving the
  existing download fallback for missing artifacts and standalone callers.
  The script retains ownership of temporary caches but does not delete a
  caller-provided directory.
  
  In https://github.com/openai/codex/actions/runs/27242495616, the
  duplicate
  download transferred 3.3 GiB and took 4 minutes 13 seconds. This should
  reduce total release time by about 4 minutes.

  Tamir Duberstein · 2026-06-10 13:15:43 -07:00
  387adc6c4b
• ci: template custom runner names by repo (#27024)

  ## Why
  
  These workflows currently hard-code the `codex` runner group and custom
  runner labels. That makes the same workflow definitions less portable
  across repository copies or renamed repos, even though the runner fleet
  follows the repository name scheme. Template the runner identities from
  the repository name so `openai/codex` still resolves to the existing
  `codex-*` runners while other repos can use their own `<repo>-*` runner
  names.
  
  ## What Changed
  
  - Replaced custom runner `group` values such as `codex-runners` with
  `${{ github.event.repository.name }}-runners`.
  - Replaced custom runner labels such as `codex-linux-x64` and
  `codex-windows-arm64` with `${{ github.event.repository.name }}-...`.
  - Covered direct `runs-on` objects, matrix `runs_on` entries, reusable
  workflow runner inputs, and release runner labels.
  
  ## Verification
  
  - Parsed all `.github/workflows/*.yml` files as YAML with Ruby.
  - Searched `.github/workflows` to confirm no hardcoded runner-field
  `codex-runners` or `codex-*` labels remain.

  Michael Bolin · 2026-06-08 11:47:23 -07:00
  2375cb6449
• [codex] Restore release symbol artifacts with line tables (#26202)

  ## Summary
  
  - Restore separate release symbol archives for macOS, Linux, and Windows
  binaries.
  - Build release binaries with `line-tables-only` debuginfo instead of
  full debuginfo.
  - Strip Unix distribution binaries after extracting symbols, preserve
  Windows PDBs, and keep symbol archives available to the release job.
  - Strip the packaged Linux `bwrap` binary before hashing it so the
  embedded digest matches the distributed bytes.
  
  ## Root cause
  
  The first symbol-artifact implementation enabled
  `CARGO_PROFILE_RELEASE_DEBUG=full`. In the June 2 release runs, macOS
  ARM primary builds reached the 90-minute timeout while still inside
  `Cargo build`. After the symbol changes were reverted, the same primary
  build completed in about 22 minutes. The archive step itself completed
  in tens of seconds when reached.
  
  Rust's `line-tables-only` debuginfo level preserves function names and
  source locations for symbolication without emitting the heavier variable
  and type information from full debuginfo.
  
  ## Validation
  
  - Ran `just fmt` from `codex-rs`.
  - Ran `just test-github-scripts` from the repository root: 23 tests
  passed.
  - Ran `bash -n` and `shellcheck` on
  `.github/scripts/archive-release-symbols-and-strip-binaries.sh`.
  - Parsed both modified workflows as YAML and ran `git diff --check`.
  - Built a macOS release smoke binary with `line-tables-only`, archived
  its dSYM through the restored script, stripped the production binary,
  and verified that `atos` resolves `symbol_smoke_function` to
  `main.rs:2`.
  - Ran Linux archive-script control-flow coverage with stubbed `objcopy`
  and `strip` commands.
  - Ran Windows PDB archive staging coverage and verified
  underscore-emitted Rust PDB names are staged under shipped hyphenated
  binary names.
  
  ## Follow-up
  
  The release workflow only runs for tags or manual dispatches, so CI
  cannot dry-run the full release matrix on this PR. The next release run
  will verify runner time and memory behavior under `line-tables-only`.

  Jeremy Rose · 2026-06-08 17:16:36 +00:00
  6d0e313e23
• Clean up Rust release workflow (#26335)

  ## Why
  PR #26252 moved macOS release signing into the tag-triggered
  `rust-release` workflow through the protected `codesigning` environment
  and Azure Key Vault. That leaves the old manual unsigned-build /
  signed-promotion handoff as dead compatibility scaffolding: it makes the
  release DAG harder to reason about and keeps paths around that the
  current release process no longer intends to operate.
  
  ## What changed
  - Remove the manual `workflow_dispatch` inputs and validation for
  `build_unsigned`, `promote_signed`, and the deprecated `sign_macos`
  flag.
  - Drop the `stage-signed-macos` job and the promotion-specific artifact
  download, re-upload, pruning, and cleanup logic.
  - Make tag-pushed releases always follow the signed release path: build,
  sign, package, finalize, publish, and then run downstream release jobs
  from `release` success.
  - Remove stale `SIGN_MACOS` / `sign_macos` conditions and outputs,
  including downstream gates for npm, DotSlash, WinGet, dev website
  deploy, and `latest-alpha-cli` branch updates.
  
  ## Verification
  - `ruby -e 'require "yaml"; YAML.load_file(ARGV.fetch(0)); puts "yaml
  ok"' .github/workflows/rust-release.yml`
  - `git diff --check`
  - `rg -n
  "workflow_dispatch|inputs\\.|release_mode|build_unsigned|SIGN_MACOS|outputs\\.sign_macos|sign_macos\\b"
  .github/workflows/rust-release.yml` returned no matches

  Shijie Rao · 2026-06-05 10:36:14 -07:00
  78eba34b41
• 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