macOS arm64 0.147.0 canonical release binary fails strict codesign verification

Open
#37,725 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, rust
Domain
release, security

Research direction

Start by reviewing release PR #37154 and the canonical GitHub and npm macOS arm64 artifacts, then reproduce the reported codesign --verify --strict and entitlement checks against the checksum-verified binary. Done means confirming the intended artifact and producing or identifying a corrected release artifact that passes strict signature verification.

Written by the indexing model from the issue text.

Description

bug CLI

The canonical Apple Silicon Codex CLI executable published in rust-v0.147.0 fails strict Apple code-signature verification.

I independently verified both distribution paths:

  • canonical GitHub release asset codex-package-aarch64-apple-darwin.tar.gz
  • npm @openai/codex@0.147.0-darwin-arm64

The GitHub archive SHA-256 matches both GitHub release metadata and codex-package_SHA256SUMS.

The extracted standalone executable and npm executable are byte-for-byte identical (cmp exit 0).

Native executable SHA-256:

19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37

Architecture:

Mach-O 64-bit executable arm64

Embedded signing metadata is parseable and reports:

Identifier=codex

TeamIdentifier=2DC432GLL2

However:

codesign --verify --strict --verbose=4 <codex>

returns:

invalid signature (code or signature have been modified)

In architecture: arm64

Entitlements inspection also reports:

warning: binary contains an invalid entitlements blob.

spctl --assess --type execute --verbose=4 returns:

internal error in Code Signing subsystem

This occurs on the exact checksum-verified canonical release bytes, not on a modified or repackaged executable.

This appears particularly relevant because the 0.147.0 release notes include PR #37154, “Use Azure Key Vault for macOS notarization.”

Could OpenAI confirm whether the above SHA-256 is the intended Apple Silicon 0.147.0 executable and whether it is expected to pass strict codesign verification? If this is a release-signing/notarization regression, is a corrected artifact planned?

I can provide the complete release metadata, hashes, codesign output, archive inventory, and npm-versus-standalone comparison if useful.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.