6 Commits

  • release: publish standalone zsh artifacts (#30114)
    ## Why
    
    The patched zsh artifacts rarely change, but
    `.github/workflows/rust-release-zsh.yml` currently runs as part of every
    Rust release. Rebuilding the same four binaries for each Codex version
    wastes release capacity and ties an independently versioned runtime
    dependency to the main release cadence.
    
    This establishes the producer side of a build-once flow. The existing
    Rust release workflow remains unchanged until the first standalone
    artifact release has been published and the checked-in DotSlash
    manifests can be updated with its URLs and checksums.
    
    ## What changed
    
    - Run the zsh release workflow for protected `codex-zsh-vX.Y.Z` tags
    instead of as a reusable workflow.
    - Validate the semantic release tag before starting the platform builds.
    - Publish the four zsh archives to a GitHub prerelease so the release
    never becomes the repository latest release.
    - Publish the generated `codex-zsh` DotSlash manifest alongside the
    archives.
    - Document how to publish the next artifact version after changing the
    pinned zsh commit or patch.
    
    ## Tag protection
    
    An active repository tag ruleset named `codex-zsh-v*.*.*` targets
    `refs/tags/codex-zsh-v*.*.*`. It restricts tag creation, updates,
    deletion, and non-fast-forward changes; requires linear history; and
    limits bypass to the configured repository role.
    
    This was verified with:
    
    ```shell
    gh api repos/openai/codex/rulesets/18140982
    ```
    
    The response reported `"enforcement":"active"`, the expected tag
    condition, and the `creation`, `update`, `deletion`, `non_fast_forward`,
    and `required_linear_history` rules.
    
    ## Rollout
    
    After this lands, publish the first `codex-zsh-vX.Y.Z` release. A
    follow-up can then update the checked-in DotSlash manifests and remove
    the zsh rebuild from `.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/30114).
    * #30116
    * __->__ #30114
  • 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.
  • [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.
  • [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@ 馃檪
  • [codex] Pin GitHub Actions workflow references (#15828)
    Pin floating external GitHub Actions workflow refs to immutable SHAs.
    
    Why are we doing this? Please see the rationale doc:
    https://docs.google.com/document/d/1qOURCNx2zszQ0uWx7Fj5ERu4jpiYjxLVWBWgKa2wTsA/edit?tab=t.0
    
    Did this break you? Please roll back and let hintz@ know
  • fix: keep zsh-fork release assets after removing shell-tool-mcp (#15644)
    ## Why
    
    `shell-tool-mcp` and the Bash fork are no longer needed, but the patched
    zsh fork is still relevant for shell escalation and for the
    DotSlash-backed zsh-fork integration tests.
    
    Deleting the old `shell-tool-mcp` workflow also deleted the only
    pipeline that rebuilt those patched zsh binaries. This keeps the package
    removal, while preserving a small release path that can be reused
    whenever `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch`
    changes.
    
    ## What changed
    
    - removed the `shell-tool-mcp` workspace package, its npm
    packaging/release jobs, the Bash test fixture, and the remaining
    Bash-specific compatibility wiring
    - deleted the old `.github/workflows/shell-tool-mcp.yml` and
    `.github/workflows/shell-tool-mcp-ci.yml` workflows now that their
    responsibilities have been replaced or removed
    - kept the zsh patch under
    `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch` and updated
    the `codex-rs/shell-escalation` docs/code to describe the zsh-based flow
    directly
    - added `.github/workflows/rust-release-zsh.yml` to build only the three
    zsh binaries that `codex-rs/app-server/tests/suite/zsh` needs today:
      - `aarch64-apple-darwin` on `macos-15`
      - `x86_64-unknown-linux-musl` on `ubuntu-24.04`
      - `aarch64-unknown-linux-musl` on `ubuntu-24.04`
    - extracted the shared zsh build/smoke-test/stage logic into
    `.github/scripts/build-zsh-release-artifact.sh`, made that helper
    directly executable, and now invoke it directly from the workflow so the
    Linux and macOS jobs only keep the OS-specific setup in YAML
    - wired those standalone `codex-zsh-*.tar.gz` assets into
    `rust-release.yml` and added `.github/dotslash-zsh-config.json` so
    releases also publish a `codex-zsh` DotSlash file
    - updated the checked-in `codex-rs/app-server/tests/suite/zsh` fixture
    comments to explain that new releases come from the standalone zsh
    assets, while the checked-in fixture remains pinned to the latest
    historical release until a newer zsh artifact is published
    - tightened a couple of follow-on cleanups in
    `codex-rs/shell-escalation`: the `ExecParams::command` comment now
    describes the shell `-c`/`-lc` string more clearly, and the README now
    points at the same `git.code.sf.net` zsh source URL that the workflow
    uses
    
    ## Testing
    
    - `cargo test -p codex-shell-escalation`
    - `just argument-comment-lint`
    - `bash -n .github/scripts/build-zsh-release-artifact.sh`
    - attempted `cargo test -p codex-core`; unrelated existing failures
    remain, but the touched `tools::runtimes::shell::unix_escalation::*`
    coverage passed during that run