Michael Bolin
891f1f4c85
## 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
codex-shell-escalation
This crate contains the Unix shell-escalation protocol implementation and the
codex-execve-wrapper executable.
codex-execve-wrapper receives the arguments to an intercepted execve(2) call and delegates the
decision to the shell-escalation protocol over a shared file descriptor (specified by the
CODEX_ESCALATE_SOCKET environment variable). The server on the other side replies with one of:
Run:codex-execve-wrappershould invokeexecve(2)on itself to run the original command within the sandboxed shell.Escalate: forward the file descriptors of the current process so the command can be run faithfully outside the sandbox. When the process completes, the server forwards the exit code back tocodex-execve-wrapper.Deny: the server has declared the proposed command to be forbidden, socodex-execve-wrapperprints an error tostderrand exits with1.
Patched zsh
We carry a small patch to Src/exec.c (see patches/zsh-exec-wrapper.patch) that adds support for EXEC_WRAPPER. The patch applies to 77045ef899e53b9598bebc5a41db93a548a40ca6 from https://git.code.sf.net/p/zsh/code. To rebuild manually:
git clone https://git.code.sf.net/p/zsh/code
git checkout 77045ef899e53b9598bebc5a41db93a548a40ca6
git apply /path/to/patches/zsh-exec-wrapper.patch
./Util/preconfig
./configure
make -j"$(nproc)"
Release artifacts are built by .github/workflows/rust-release-zsh.yml when a
codex-zsh-vX.Y.Z tag is pushed. When the zsh commit or patch changes, publish
the next version tag and update the checked-in DotSlash manifests to use the new
release.