438 Commits

• 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
• ci: use issue triage environment for issue workflows (#25134)

  ## Summary
  
  This adds `environment: issue-triage` to the Codex-calling issue
  workflow jobs so they can read the GitHub Environment Secret while
  staying on GitHub-hosted runners for public issue-triggered workflows.

  Eric Traut · 2026-05-29 12:06:55 -07:00
  20da4c37c5
• Move Bazel Windows jobs onto codex-runners (#24952)

  The codex-windows runner group should be much faster than the default
  GHA runners. Since bazel jobs on windows are frequently the long pole
  for PRs checks, this will hopefully get people landing a bit faster.

  Adam Perry @ OpenAI · 2026-05-28 12:43:04 -07:00
  9dd39f334e
• Revert "Add app-server startup benchmark crate" (#24937)

  Reverts openai/codex#24651, broke musl job
  https://github.com/openai/codex/actions/runs/26585495205/job/78330166927

  Adam Perry @ OpenAI · 2026-05-28 17:49:41 +00:00
  c2508db60d
• 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
• Add app-server startup benchmark crate (#24651)

  ## Summary
  - Add a new `app-server-start-bench` crate to measure app-server startup
  performance
  - Wire the benchmark into the workspace and Bazel build so it can be run
  consistently
  - Update lockfiles and repo automation to account for the new package

  Adam Perry @ OpenAI · 2026-05-28 08:46:30 -07:00
  bd2a732923
• [codex] Stage Python SDK beta versions from release tags (#24872)

  ## Summary
  - Treat `sdk/python` as a development template with source version
  `0.0.0-dev`, matching the existing Python runtime packaging pattern.
  - Have `python-v*` tags supply the published SDK beta version through
  the existing `stage-sdk --sdk-version` path.
  - Remove the workflow check requiring a source version bump for each
  beta release and remove its now-unused host Python setup step.
  - Keep the reviewed runtime dependency pin at
  `openai-codex-cli-bin==0.132.0`.
  - Remove beta-number-specific documentation so it does not need editing
  for each publish.
  
  ## Why
  The package staging script already writes the release version into the
  artifact. Requiring the checked-in SDK template version to match every
  tag adds release-only source churn without changing the package users
  receive.
  
  ## Validation
  - Not run locally; relying on online CI for this workflow and metadata
  change.
  
  ## Release
  After this PR lands, publish the next beta by pushing tag
  `python-v0.1.0b2` from merged `main`.

  Ahmed Ibrahim · 2026-05-27 23:24:42 -07:00
  46946bb91c
• [codex] Prepare Python SDK beta documentation and package metadata (#24836)

  ## Why
  
  The initial public `openai-codex` beta should read and install like a
  normal published Python package before a release tag is created. This
  follows merged PR #24828, which establishes the independent SDK beta
  release plumbing and exact runtime dependency.
  
  ## What changed
  
  - Rewrote `sdk/python/README.md` as a compact PyPI-facing beta package
  page: published installation, one quickstart, short login examples,
  built-in help, and links to deeper guides.
  - Updated the getting-started guide, API reference, FAQ, and examples
  index to present the published beta consistently without repeating
  onboarding in the package landing page or reference page.
  - Made `pip install openai-codex` the primary install path while beta
  releases are the only published SDK releases, with `--pre` documented
  for opting into prereleases after a stable release exists.
  - Added curated `help()` / `pydoc` docstrings across the public API and
  generated public convenience methods through
  `scripts/update_sdk_artifacts.py`.
  - Declared the repository `Apache-2.0` license expression and
  Documentation URL in package metadata, without introducing a duplicated
  SDK-local license file.
  - Kept the source distribution focused on installable package material
  (`src/openai_codex`, `README.md`, and `pyproject.toml`); the repository
  docs and runnable examples remain linked from the PyPI README.
  - Built release artifacts in an Alpine container on the Ubuntu runner,
  matching Python SDK CI and allowing type generation to install the
  published `musllinux` runtime wheel.
  - Added `twine check --strict` to the release workflow so malformed PyPI
  metadata or rendered README content fails before publishing.
  - Added focused SDK assertions for beta metadata, the exact runtime pin,
  source distribution contents, and the built-in Python documentation
  surface.
  
  ## Validation
  
  - Ran `uv run --frozen --extra dev ruff check
  scripts/update_sdk_artifacts.py src/openai_codex
  tests/test_public_api_signatures.py
  tests/test_artifact_workflow_and_binaries.py` before the final
  README-only reductions and review-fix follow-ups.
  - Built `openai_codex-0.1.0b1-py3-none-any.whl` and
  `openai_codex-0.1.0b1.tar.gz` before the final README-only reductions
  and review-fix follow-ups.
  - Ran `python -m twine check --strict` on both built artifacts before
  the final README-only reductions and review-fix follow-ups.
  - Verified artifact metadata reports `Apache-2.0` without a duplicated
  SDK-local license file.
  - Verified `inspect.getdoc(...)` resolves documentation for the package,
  `Codex`, `CodexConfig`, and key generated thread methods.
  - Rebased the documentation/readiness change onto merged PR #24828
  without changing the intended SDK or workflow file contents.
  - Final verification is delegated to online CI for this PR.

  Ahmed Ibrahim · 2026-05-27 18:29:05 -07:00
  eb1cc3824c
• [codex] Add independent beta release for the Python SDK (#24828)

  ## Why
  
  `openai-codex` needs a beta release lifecycle without requiring beta
  releases of its pinned runtime package. Previously, SDK staging rewrote
  its runtime dependency to the SDK version, which made an SDK-only beta
  impossible.
  
  ## What changed
  
  - Set the initial SDK beta version to `0.1.0b1` and pin it to published
  stable `openai-codex-cli-bin==0.132.0`.
  - Decoupled SDK release staging from runtime versioning so it preserves
  the reviewed exact runtime pin.
  - Added a `python-v*` tag workflow that builds and publishes only
  `openai-codex` through PyPI trusted publishing.
  - Removed the Beta classifier from runtime package metadata for future
  runtime publications.
  - Regenerated protocol-derived SDK models from the selected stable
  runtime package.
  
  `0.132.0` is the newest stable runtime admitted by the checked-in
  dependency date fence and retains the Linux wheel family currently used
  by SDK CI.
  
  ## Release setup
  
  Before pushing `python-v0.1.0b1`, configure PyPI trusted publishing for
  the `openai-codex` project with workflow `python-sdk-release.yml`,
  environment `pypi`, and job `publish-python-sdk`.
  
  ## Validation
  
  - `uv run --frozen --extra dev ruff check src/openai_codex scripts
  examples tests`
  - Parsed `.github/workflows/python-sdk-release.yml` with PyYAML.
  - Built staged release artifacts locally:
  `openai_codex-0.1.0b1-py3-none-any.whl` and
  `openai_codex-0.1.0b1.tar.gz`.
  - Verified wheel metadata pins `openai-codex-cli-bin==0.132.0`.
  - Tests are deferred to online CI for this PR.

  Ahmed Ibrahim · 2026-05-27 17:57:51 -07:00
  4d0c4cd058
• 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
• release: build macOS x64 zsh artifact (#24165)

  ## Why
  
  The zsh release workflow currently publishes macOS arm64 and Linux zsh
  fork artifacts, but no macOS x64 artifact. The Codex package builder
  therefore cannot include codex-resources/zsh/bin/zsh for
  x86_64-apple-darwin packages.
  
  ## What Changed
  
  - Added an x86_64-apple-darwin row to the macOS zsh release matrix.
  - Runs that row on macos-15-large, the Intel macOS runner appropriate
  for the native zsh build.
  - Added the matching macos-x86_64 platform to the zsh DotSlash publish
  config so the generated release manifest can reference the new tarball.

  Michael Bolin · 2026-05-22 17:08:59 -07:00
  ed47f1ab1e
• [codex] Add image re-encoding benchmarks (#23935)

  ## Summary
  - add Divan benchmarks for prompt image re-encoding paths
  - wire the image benchmark smoke test into Rust CI workflows
  
  ## Why
  Image prompt handling includes re-encoding work that benefits from
  repeatable benchmark coverage so changes can be measured in CI and
  locally.
  
  This already helped identify a potential regression from changing compiler flags.
  
  ## Impact
  Developers can run and compare the new image re-encoding benchmarks, and
  CI exercises the benchmark target via the Rust benchmark smoke test.

  Adam Perry @ OpenAI · 2026-05-22 22:38:40 +00:00
  7924743c38
• 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
• npm: remove legacy package artifact synthesis (#23836)

  ## Why
  
  `rust-release` now publishes `codex-package-<target>.tar.gz` as the
  canonical native package payload. npm staging should consume those
  archives directly instead of keeping legacy synthesis code that fetched
  `rg`, copied standalone binaries, and rebuilt an approximate package
  layout.
  
  That also means the package builder should not know the internal shape
  of `codex-package`. It should extract and copy the target payload
  wholesale so future layout changes stay localized to the archive
  producer.
  
  The release job stages `codex`, `codex-responses-api-proxy`, and
  `codex-sdk` together, so native artifact download should be filtered,
  observable, and shared across component installs. Since that native
  hydration is now only used by release staging, keeping a separate
  `install_native_deps.py` CLI adds an extra wrapper without a real
  caller.
  
  ## What Changed
  
  - Removed legacy `codex-package` synthesis and related compatibility
  flags from npm staging.
  - Folded the remaining native artifact hydration code into
  `scripts/stage_npm_packages.py` and deleted
  `codex-cli/scripts/install_native_deps.py`.
  - Made platform package staging copy the full extracted target directory
  instead of enumerating package entries.
  - Kept non-`codex-package` native components under their component
  directory name instead of using a legacy destination map.
  - Split native staging by component set while sharing one
  workflow-artifact cache across the invocation.
  - Changed workflow artifact download to select target artifacts by name,
  print sizes/progress, and reuse cached artifacts.
  - Removed the implicit `CI=true` default from `build_npm_package.py`;
  local CI-shaped runs should set that environment explicitly.
  - Kept `npm pack` cache/log output in its temporary directory so packing
  does not write to the user npm cache.
  
  ## Verification
  
  - `python3 -m py_compile scripts/stage_npm_packages.py
  codex-cli/scripts/build_npm_package.py`
  - `python3 -m unittest discover -s scripts/codex_package -p "test_*.py"`
  - `scripts/stage_npm_packages.py --help`
  - `codex-cli/scripts/build_npm_package.py --help`
  - Ran the release-shaped staging command from `rust-release.yml` against
  workflow run https://github.com/openai/codex/actions/runs/26240748758
  with `CI=true` set locally to match GitHub Actions:
  
  ```sh
  CI=true python3 ./scripts/stage_npm_packages.py \
    --release-version 0.133.0 \
    --workflow-url https://github.com/openai/codex/actions/runs/26240748758 \
    --package codex \
    --package codex-responses-api-proxy \
    --package codex-sdk
  ```
  
  That completed successfully, downloaded only the six target artifacts
  once, reused the cache for `codex-responses-api-proxy`, and produced all
  nine npm tarballs. Generated tarballs and staging/artifact temp dirs
  were cleaned afterward.

  Michael Bolin · 2026-05-21 20:43:48 +00:00
  b20e969f23
• 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
• ci: run Codex package builder tests (#23760)

  ## Why
  
  #23752 and #23759 add Python unit tests for the Codex package builder,
  but the root CI workflow did not run tests under
  `scripts/codex_package`. That left the `zstd` resolution and
  prebuilt-resource packaging behavior covered locally without a CI check.
  
  ## What changed
  
  - Add a root CI step in `.github/workflows/ci.yml` that runs `python3 -m
  unittest discover -s scripts/codex_package -p "test_*.py"`.
  - Keep the step with the existing Python verification checks before
  Node/pnpm setup.
  
  ## Verification
  
  - `python3 -m unittest discover -s scripts/codex_package -p "test_*.py"`
  - `python3 -m py_compile scripts/codex_package/*.py`

  Michael Bolin · 2026-05-20 17:00:55 -07:00
  0b5cf85b64
• 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
• dotslash: publish Codex entrypoints from package archives (#23638)

  ## Summary
  
  DotSlash should resolve the same canonical package archives used by
  standalone installers and npm platform packages, rather than continuing
  to point at single-binary zstd artifacts or the older Linux bundle
  archive.
  
  This updates the Codex CLI and `codex-app-server` DotSlash release
  config entries to match `codex-package-<target>.tar.gz` and
  `codex-app-server-package-<target>.tar.gz`, with paths that select
  `bin/codex` or `bin/codex-app-server` inside the extracted package. The
  other helper outputs stay on their existing per-binary artifacts for
  now.
  
  ## Test plan
  
  - `python3 -m json.tool .github/dotslash-config.json > /dev/null`
  - Ran a Python regex smoke test that checked every updated `codex` and
  `codex-app-server` platform entry against the archive names emitted by
  `.github/scripts/build-codex-package-archive.sh`.

  Michael Bolin · 2026-05-20 12:18:10 -07:00
  cb05de6724
• 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
• Fan out rust-ci-full nextest by platform (#23358)

  ## Why
  
  `rust-ci-full` was paying the full Cargo nextest build-and-run cost once
  per platform, with Windows ARM64 as the long pole. This change moves the
  heavy work into one reusable per-platform flow: build a nextest archive
  once, then replay it across four shards so the platform lane spends less
  time running tests serially. For Windows ARM64, the archive is
  cross-compiled on Windows x64 and replayed on native Windows ARM64
  shards so the slow ARM64 machine is used for execution rather than
  compilation.
  
  ## What changed
  
  - split the `rust-ci-full` nextest matrix into five explicit
  per-platform reusable-workflow calls
  - add `.github/workflows/rust-ci-full-nextest-platform.yml` to build one
  archive, upload timings/helpers, replay four nextest shards, upload
  per-shard JUnit, and roll the shard status back up per platform
  - add Windows CI helpers for Dev Drive setup and MSVC ARM64 linker
  environment export so the Windows ARM64 archive can be produced on
  Windows x64
  - keep the existing Cargo git CLI fetch hardening inside the reusable
  workflow, since caller workflow-level `env` does not flow through
  `workflow_call`
  - document the archive-backed shard shape in
  `.github/workflows/README.md`
  - raise the default nextest slow timeout to 30s so the sharded full-CI
  path does not treat every >15s test as stuck
  
  ## Verification
  
  - validated the archive/shard flow with live GitHub Actions runs on this
  PR branch
  - Windows ARM64 cross-compile latency on completed runs:
  - https://github.com/openai/codex/actions/runs/26118759651: `34m30s`
  lane e2e, `17m16s` archive build, `9m55s` shard phase
  - https://github.com/openai/codex/actions/runs/26120777976: `30m36s`
  lane e2e, `17m21s` archive build, `6m50s` shard phase
  - comparable pre-cross-compile sharded Windows ARM64 runs were `55m01s`,
  `50m21s`, and `46m42s`, so the completed cross-compile runs improved the
  lane by roughly `12m` to `24m` versus the prior range
  - latest corrected cross-compile run:
  https://github.com/openai/codex/actions/runs/26120777976
    - Windows ARM64 archive built successfully on Windows x64
  - native Windows ARM64 shards started immediately after the archive
  upload
  - 3/4 Windows ARM64 shards passed; the failing shard hit the same
  existing `code_mode` test failure seen outside this lane
  - downloaded failed-shard JUnit XML from the validation runs and
  confirmed the remaining red is from known test failures, not
  archive/shard wiring
  - no local Codex tests run per repo guidance
  
  ## Notes
  
  - this PR does not change developers.openai.com documentation

  starr-openai · 2026-05-19 17:54:41 -07:00
  64ef6cd1e4
• CI: Customize v8 building (#22086)

  ## Summary
  
  Move the rusty_v8 artifact production into hermetic Bazel path and bump
  the `v8` crate to `147.4.0`
  
  The new flow builds V8 release artifacts from source for Darwin and
  Linux targets, publishes both the current release-compatible artifacts
  and sandbox-enabled variants, and keeps Cargo consumers on prebuilt
  binaries by continuing to feed the `v8` crate the archive and generated
  binding files it already expects.
  
  ## Why
  
  We need control over V8 build-time features without giving up prebuilt
  artifacts for downstream Cargo builds.
  
  Upstream `rusty_v8` already supports source-only features such as
  `v8_enable_sandbox`, but its normal prebuilt release assets do not cover
  every feature combination we need. Building the artifacts ourselves lets
  us enable settings such as the V8 sandbox and pointer compression at
  artifact build time, then publish those outputs so ordinary Cargo builds
  can still consume prebuilts instead of compiling V8 locally.
  
  This keeps the fast consumer experience of prebuilt `rusty_v8` archives
  while giving us a reproducible path to ship featureful variants that
  upstream does not currently publish for us.
  
  ## Implementation Notes
  
  The Bazel graph in this PR is not copied wholesale from `rusty_v8`;
  `rusty_v8`'s normal source build is still GN/Ninja-based.
  
  Instead, this change starts from upstream V8's Bazel rules and adapts
  them to Codex's hermetic toolchains and dependency layout. Where we
  intentionally follow `rusty_v8`, we mirror its existing artifact
  contract:
  
  - the same `v8` crate version and generated binding expectations
  - the same sandbox feature relationship, where sandboxing requires
  pointer compression
  - the same custom libc++ model expected by Cargo's default
  `use_custom_libcxx` feature
  - the same release-style archive plus `src_binding` outputs consumed by
  the `v8` crate
  
  To preserve that contract, the Bazel release path pins the libc++,
  libc++abi, and llvm-libc revisions used by `rusty_v8 v147.4.0`, builds
  release artifacts with `--config=rusty-v8-upstream-libcxx`, and folds
  the matching runtime objects into the final static archive.
  
  ## Windows
  
  Windows is annoyingly handled differently.
  
  Codex's current hermetic Bazel Windows C++ platform is `windows-gnullvm`
  / `x86_64-w64-windows-gnu`, while upstream `rusty_v8` publishes Windows
  prebuilts for `*-pc-windows-msvc`. Those are different ABIs, so the
  Bazel graph cannot truthfully reproduce the upstream MSVC artifacts
  until we add a real MSVC-targeting C++ toolchain.
  
  For now:
  
  - Windows MSVC consumers continue to use upstream `rusty_v8` release
  archives.
  - Windows GNU targets are built in-tree so they link against a matching
  GNU ABI.
  - The canary workflow separately exercises upstream `rusty_v8` source
  builds for MSVC sandbox artifacts, but MSVC is not yet part of the
  Bazel-produced release matrix.
  
  ## Validation
  This PR is technically self validating through CI. I have already
  published it as a release tag so the artifacts from this branch are
  published to
  https://github.com/openai/codex/releases/tag/rusty-v8-v147.4.0 CI for
  this PR should therefore consume our own release targets. I have also
  locally tested for linux and darwin.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Channing Conger · 2026-05-18 21:33:05 -07:00
  7cdeab33d1
• 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
• Reduce rust-ci-full Windows nextest timeout flakes (#23253)

  ## Why
  Recent `rust-ci-full` failures were dominated by transient Windows
  timeout clusters in process-heavy tests such as `suite::resume`,
  `suite::cli_stream`, `suite::auth_env`,
  `start_thread_uses_all_default_environments_from_codex_home`, and
  `connect_stdio_command_initializes_json_rpc_client_on_windows`.
  
  The goal here is to make those known flaky paths less likely to fail
  full CI without relaxing the global nextest timeout policy.
  
  ## What changed
  - Enable one global nextest retry with `retries = 1` so a single
  transient failure can recover.
  - Add a `windows_process_heavy` test group with `max-threads = 2` for
  the recurring Windows subprocess/session-heavy timeout families.
  - Add Windows-only slow-timeout overrides for that process-heavy group.
  - Add a narrower Windows-only timeout override for
  `start_thread_uses_all_default_environments_from_codex_home`, which
  still exceeded the broader Windows bucket in both Windows full-CI lanes.
  - Increase the `rust-ci-full` nextest job timeout from `45m` to `60m` so
  Windows ARM64 still has job-level headroom after retries and targeted
  per-test timeout increases.
  - Keep the global `slow-timeout` unchanged at `15s`.
  
  ## Validation
  Validated through `rust-ci-full` GitHub Actions reruns on this PR.
  
  Observed improvement on the tuned Windows lanes:
  - Windows x64 went from `5 timed out` to `0 timed out`.
  - Windows ARM64 went from `2 timed out` to `0 timed out`.
  - `start_thread_uses_all_default_environments_from_codex_home` recovered
  as a flaky pass on Windows ARM64 instead of timing out.
  
  The remaining failing tests in those runs were unrelated hard failures
  outside this nextest timeout tuning.

  starr-openai · 2026-05-18 13:06:39 -07:00
  732b12b1ef
• Upload rust full CI JUnit reports (#23273)

  ## Why
  
  `rust-ci-full` failures currently leave downstream investigation
  reconstructing basic test facts from raw logs. `cargo nextest` can emit
  standard JUnit XML for each lane, which gives us a small structured
  artifact for post-run failure analysis without changing the test
  execution model.
  
  ## What changed
  
  - enable nextest JUnit output in `codex-rs/.config/nextest.toml`
  - upload the lane-scoped JUnit XML artifact from each `rust-ci-full`
  test lane
  
  ## Verification
  
  - `rust-ci-full` run `26018931531` on head
  `52d77c60e79b36859d944ef28a36b014055c5c48` produced JUnit artifacts for
  macOS, Linux x64 remote, Windows x64, and Windows ARM64 test lanes
  - `rust-ci-full` run `26021241006` on the same head produced the missing
  Linux ARM JUnit artifact after the first run lost that runner before
  export
  - downloaded all five lane JUnit artifacts and verified each contains
  non-empty test counters and failure data

  starr-openai · 2026-05-18 11:10:37 -07:00
  8c14b08dd1
• 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
• Workflow updates (#22582)
  viyatb-oai · 2026-05-15 12:41:18 -07:00
  6afe00efda
• 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
• make rust-release-prepare use env secret (#22702)

  made a `rust-release-prepare` environment with the necessary API key as
  an environment secret. use this in the workflow rather than the action
  secret.
  
  once this merges and i confirm it works as intended, ill rm the action
  secret.

  sayan-oai · 2026-05-14 21:45:53 +00:00
  d346957288
• 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
• Deprecate issue labeler (#22574)
  Max Burkhardt · 2026-05-13 19:55:31 -04:00
  4fca5c32da
• 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
• Shard Bazel Windows tests across jobs (#22408)

  ## Summary
  - split the single PR-blocking Bazel Windows test leg into four Windows
  shard jobs
  - preserve the existing required Windows Bazel check name with a
  lightweight aggregate gate
  - keep Linux/macOS Bazel test jobs and the separate Windows
  clippy/release jobs unchanged
  
  ## Why
  The ordinary PR Windows Bazel test leg was one GitHub Actions job, so
  Bazel only had in-job parallelism. This gives that lane real job-level
  fanout across separate Windows hosts while keeping the target set
  disjoint via stable label hashing.
  
  ## Evidence
  - final pre-rebase green run: `25774733562`
  - Windows shard target counts: `61/212`, `48/212`, `52/212`, `51/212`
  - Windows test fanout completed in about 7m29s versus a recent
  monolithic median around 22m26s
  
  ## Notes
  - this is scoped to the Bazel Windows test leg only
  - each shard keeps the existing Windows cross-compile/RBE path and
  restores the former monolithic Windows test cache
  - shard jobs do not upload duplicate repository caches after test work,
  keeping cache cleanup off the PR-blocking shard path
  - no local validation run; relying on GitHub Actions for the
  workflow-shaped check
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-13 12:46:51 -07:00
  d666238b40
• 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
• [8/8] Add Python SDK Ruff formatting (#22021)

  ## Why
  
  The Python SDK needs the same tight formatter/lint loop as the rest of
  the repo: a safe Ruff autofix pass, Ruff formatting, editor save
  behavior, and CI checks that catch drift. Without that loop, SDK changes
  can land with formatting or import ordering that differs from what
  reviewers and CI expect.
  
  ## What
  
  - Add Ruff configuration to `sdk/python/pyproject.toml`, excluding
  generated protocol code and notebooks from the normal lint/format pass.
  - Update `just fmt` so it still formats Rust and also runs Python SDK
  Ruff autofix and formatting.
  - Add Python SDK CI steps for `ruff check` and `ruff format --check`
  before pytest.
  - Recommend the Ruff VS Code extension and enable Python
  format/fix/organize-on-save so Cmd+S uses the same tooling.
  - Apply the resulting Ruff formatting to SDK Python files, examples, and
  the checked-in generated `v2_all.py` output emitted by the pinned
  generator.
  - Add a guard test for the `just fmt` recipe so it keeps working from
  both Rust and Python SDK working directories.
  
  ## Stack
  
  1. #21891 `[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. This PR `[8/8]` Add Python SDK Ruff formatting
  
  ## Verification
  
  - Added `test_root_fmt_recipe_formats_rust_and_python_sdk` for the
  shared format recipe.
  - Ran `just fmt` after the recipe update.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-12 01:10:29 +03:00
  aa9e8f0262
• [3/8] Run Python SDK tests in CI (#21895)

  ## Why
  
  The Python SDK stack now depends on packaging metadata, pinned runtime
  wheels, generated artifacts, async behavior, and stream interleaving.
  Those checks need to run in CI so future changes cannot bypass the SDK
  test suite.
  
  ## What
  
  - Add a dedicated `python-sdk` job to `.github/workflows/sdk.yml`.
  - Run the job in `python:3.12-alpine` so dependency resolution exercises
  the pinned musl runtime wheel.
  - Keep the Python SDK test job parallel to the existing SDK job instead
  of serializing the full workflow.
  
  ## Stack
  
  1. #21891 `[1/8]` Pin Python SDK runtime dependency
  2. #21893 `[2/8]` Generate Python SDK types from pinned runtime
  3. This PR `[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
  
  - The added workflow job installs the SDK with `uv sync --extra dev
  --frozen` and runs the Python SDK pytest suite.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-12 00:53:36 +03:00
  3e2936dd0e
• [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
• ci: check out PR head commits in workflows (#21835)

  ## Why
  
  PR CI should test the exact commit that was pushed to the PR branch. By
  default, GitHub's `pull_request` event checks out a synthetic merge
  commit from `refs/pull/<number>/merge`, so the tested tree can include
  an implicit merge with the current base branch instead of matching the
  pushed head SHA.
  
  Using the PR head SHA makes each check result correspond to a concrete
  commit the author submitted. This also behaves better for stacked PR
  workflows, including Sapling stacks and other Git stack tooling: a
  middle PR's head commit already contains the lower stack changes in its
  tree, without pulling in commits above it or GitHub's temporary merge
  ref.
  
  ## What Changed
  
  - Set every `actions/checkout` in `pull_request` workflows under
  `.github/workflows` to use `github.event.pull_request.head.sha` on PR
  events and `github.sha` otherwise.
  - Updated `blob-size-policy` to compare
  `github.event.pull_request.base.sha` and
  `github.event.pull_request.head.sha`, since it no longer checks out
  GitHub's merge commit where `HEAD^1`/`HEAD^2` represented the PR range.
  
  ## Verification
  
  - Parsed the edited workflow YAML files with Ruby.
  - Checked that every checkout block in the `pull_request` workflows has
  the PR-head `ref`.

  Michael Bolin · 2026-05-08 15:14:33 -07:00
  24111790f0
• Enable --deny-warnings for cargo shear (#21616)

  ## Summary
  
  In https://github.com/openai/codex/pull/21584, we disabled doctests for
  crates that lack any doctests. We can enforce that property via `cargo
  shear --deny-warnings`: crates that lack doctests will be flagged if
  doctests are enabled, and crates with doctests will be flagged if
  doctests are disabled.
  
  A few additional notes:
  
  - By adding `--deny-warnings`, `cargo shear` also flagged a number of
  modules that were not reachable at all. Some of those have been removed.
  - This PR removes a usage of `windows_modules!` (since `cargo shear` and
  `rustfmt` couldn't see through it) in favor of simple `#[cfg(target_os =
  "windows")]` macros. As a consequence, many of these files exhibit churn
  in this PR, since they weren't being formatted by `rustfmt` at all on
  main.
  - Again, to make the code more analyzable, this PR also removes some
  usages of `#[path = "cwd_junction.rs"]` in favor of a more standard
  module structure. The bin sidecar structure is still retained, but,
  e.g., `windows-sandbox-rs/src/bin/command_runner.rs‎` was moved to
  `windows-sandbox-rs/src/bin/command_runner/main.rs`, and so on.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-08 20:29:00 +00:00
  7c9731c9af
• 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
• Use CARGO_NET_GIT_FETCH_WITH_CLI in rust-ci-full for more reliable git fetches (#21628)

  Cargo uses libgit2 by default. In uv, we gave up this entirely and
  always call out to the git CLI because it is much more reliable. This is
  a part of my attempt to reduce flakes in `rust-ci-full`.

  Zanie Blue · 2026-05-08 09:53:21 -07:00
  47f1d7b40b
• Fix rust-ci-full failures due to missing bwrap (#21604)

  Since https://github.com/openai/codex/pull/21255, `rust-ci-full` has
  been failing due to a missing `bwrap`.
  
  ```
  thread 'main' panicked at linux-sandbox/src/launcher.rs:43:13:
  bubblewrap is unavailable: no system bwrap was found on PATH and no bundled codex-resources/bwrap binary was found next to the Codex executable
  ```
  
  Since the happy path is now to use the system binary, let's ensure
  that's installed.
  
  
  https://github.com/openai/codex/pull/21604/commits/8d5182663158ee2d15965f39eed26ffa339ecb7d
  was necessary for the `bwrap` executable to be discoverable when the
  working directory is `/`.
  
  I ran `rust-ci-full` at
  https://github.com/openai/codex/actions/runs/25528074506
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Zanie Blue · 2026-05-08 09:52:19 -07:00
  05ffa0b1d0