Files
codex/.github/workflows
malsamiri-oai f363ed70cc fix(release): add missing Intel V8 signing entitlement (#30953)
## Why

Intel macOS release binaries crash on the first Code Mode tool call
while V8 creates its code range. The x86_64 V8 allocator later makes a
non-`MAP_JIT` reservation executable, which Hardened Runtime rejects
when the signature contains only `com.apple.security.cs.allow-jit`.

Tracks
[SE-8006](https://linear.app/openai/issue/SE-8006/intel-macos-codex-cli-crashes-in-v8-startup-on-gpt-56-sol-tool-calls).
Fixes #28390.

## What

- add an expanded entitlement profile only for x86_64 `codex` and
`codex-app-server`, the release binaries that link V8
- keep arm64 and `codex-responses-api-proxy` on the existing narrower
profile
- share one fail-closed target/binary selector between signing and final
verification
- verify the expected Mach-O architecture and exact entitlement
dictionary for the signed binary, tar.gz, zstd, package, and DMG copies

## Verification

- `just test-github-scripts` (34 tests)
- `UV_CACHE_DIR=/private/tmp/codex-uv-cache just fmt-check`
- `bash -n .github/scripts/macos-signing/select_codex_entitlements.sh`
- `plutil -lint` on both entitlement profiles
- parsed `rust-release.yml` as YAML
- `git diff --check`
- ad-hoc Hardened Runtime signing smoke on an x86_64 Mach-O slice:
strict `codesign` verification passed; the Codex profile contained
exactly both keys and the proxy profile retained exactly `allow-jit`

## Release validation

Run a native Intel smoke of the final Developer ID-signed x86_64 Codex
binary through V8 isolate creation before shipping. PR #30849 is
diagnostic scaffolding, but its non-sandbox release job currently fails
in the harness before V8 starts, so it is not counted as coverage here.
2026-07-07 16:47:21 +00:00
..

Workflow Strategy

The workflows in this directory are split so that pull requests get fast, review-friendly signal while main still gets the full cross-platform verification pass.

Pull Requests

  • bazel.yml is the main pre-merge verification path for Rust code. It runs Bazel test and Bazel clippy on the supported Bazel targets, including the generated Rust test binaries needed to lint inline #[cfg(test)] code.
  • rust-ci.yml keeps the Cargo-native PR checks intentionally small:
    • cargo fmt --check
    • cargo shear
    • argument-comment-lint on Linux, macOS, and Windows
    • tools/argument-comment-lint package tests when the lint or its workflow wiring changes

Post-Merge On main

  • bazel.yml also runs on pushes to main. This re-verifies the merged Bazel path and helps keep the BuildBuddy caches warm.
  • rust-ci-full.yml is the full Cargo-native verification workflow. It keeps the heavier checks off the PR path while still validating them after merge:
    • the full Cargo clippy matrix
    • the full Cargo nextest matrix via per-platform archive-backed shards
    • Windows ARM64 nextest archives cross-compiled on Windows x64, then replayed on native Windows ARM64 shards
    • release-profile Cargo builds
    • cross-platform argument-comment-lint
    • Linux remote-env tests

Rule Of Thumb

  • If a build/test/clippy check can be expressed in Bazel, prefer putting the PR-time version in bazel.yml.
  • Keep rust-ci.yml fast enough that it usually does not dominate PR latency.
  • Reserve rust-ci-full.yml for heavyweight Cargo-native coverage that Bazel does not replace yet.