macOS arm64 0.147.0 canonical release binary fails strict codesign verification

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #37324

Powered by Codex Action

Additional data point: after updating the current ChatGPT/Codex macOS app, I checked its bundled native Codex binary. It reports codex-cli 0.147.0-alpha.6.5 and, unlike the public stable 0.147.0 standalone/npm binary from this issue, it passes codesign --verify --strict with valid on disk and satisfies its Designated Requirement under OpenAI Team ID 2DC432GLL2.

I also noticed #38340 now reports a separate macOS 0.147.0 distribution problem involving a missing notarization ticket. That is a different failure mode, but it appears related to the same stable macOS release/signing/notarization boundary.

Could a maintainer confirm whether stable 0.147.0 for macOS is affected by a release signing/notarization defect, and whether a corrected stable standalone CLI artifact or newer stable release is expected?

A release-pipeline data point that reframes this: the CI pipeline both signs and strict-verifies these exact bytes — codesign --verify --strict runs right after signing and again at artifact assembly (.github/workflows/rust-release.yml#L718-L731, #L1030-L1060, signing with per-binary entitlements at #L562-L575). Those jobs run on macos-15 runners. Your verification of byte-identical content fails on macOS 26.5.2.

Since the same bytes pass one codesign and fail another, this is a verifier-toolchain divergence, and your warning: binary contains an invalid entitlements blob points at the classic culprit: entitlements encoding. Newer codesign/AMFI generations require the DER entitlements representation and reject signatures whose entitlements blob only carries the legacy form (or a DER form the newer parser considers malformed). An older signing toolchain can happily produce — and verify — a blob that macOS 26 rejects wholesale, which then also explains spctl erroring and the Gatekeeper "malware" flavor of this report in #38340.

Fix shape for the release side: (1) sign with a toolchain that emits current DER entitlements (newer runner image or explicit --generate-entitlement-der); (2) add a CI verification step on the newest available macOS image, not only the signing host — the pipeline's own strict verify created false confidence here; (3) re-publish affected assets once verified. Worth also confirming notarization/stapling for the standalone archive path, since spctl failure has that as a second possible layer.

Additional data point: the problem persists in the npm-distributed Codex CLI 0.149.1 on macOS 26.5.2 (25F84, arm64).

codesign --verify --strict --verbose=4 <0.149.1-native-binary>
<binary>: invalid signature (code or signature have been modified)
In architecture: arm64

Identifier=codex
TeamIdentifier=2DC432GLL2
CDHash=2dc305c9661e74a6f38c37bf8eebdae89c37f6e8
SHA-256=f0d8762236594359b60cfbe17f4c7e945a3ce8d1c91e74778838c968d250fb6c

In this occurrence, updating the CLI also coincided with existing Terminal/Codex process chains losing ~/Desktop TCC access (Operation not permitted) even though their TCC rows remained allowed. A genuinely new Terminal.app instance restored access. I filed the TCC/update impact separately in #40567 and linked this issue as the closest release-signing match. Causality is not yet proven, but the strict-signature failure definitely continues in 0.149.1 on macOS 26.

Update with a potentially important reproduction change:

I re-tested the exact same native Codex 0.147.0 arm64 binary from the original report on the same Mac.

Binary SHA-256:

19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37

Current host:

macOS 26.5.1
Build 25F80
arm64

The binary still reports:

codex-cli 0.147.0

codesign -d --verbose=4 shows:

Identifier: codex
TeamIdentifier: 2DC432GLL2
Authority: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Timestamp: Aug 6, 2026 10:17:46 PM

However, the original strict-verification failure is not currently reproducible with these exact bytes.

codesign --verify --strict --verbose=4 <codex> now returns:

valid on disk

satisfies its Designated Requirement

with:

codesign_exit=0

Entitlements also decode successfully and contain:

com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory

spctl --assess --type execute --verbose=4 still exits 3, but now reports:

rejected (the code is valid but does not seem to be an app)

That is materially different from the original internal error in Code Signing subsystem result.

So at this point, the exact SHA-256 originally reported as failing strict verification now passes strict codesign verification on macOS 26.5.1.

I do not yet know what changed between the original failing verification and this successful re-test, so I would not treat this as confirmation that the underlying release issue is fully resolved. But it does mean the original failure is no longer reproducible on this host with the same binary bytes.

Follow-up controlled A/B result after updating macOS:

I kept the Codex installation unchanged and re-tested the exact same native Codex 0.147.0 arm64 binary after updating the host from macOS 26.5.1 (25F80) to macOS 26.6.2 (25G83).

The binary SHA-256 remained exactly:

19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37

On macOS 26.6.2:

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

still returns:

valid on disk

satisfies its Designated Requirement

with codesign_exit=0.

The entitlements still decode successfully.

spctl --assess --type execute --verbose=4 remains unchanged:

rejected (the code is valid but does not seem to be an app)

with spctl_exit=3.

So, in this controlled same-bytes comparison, updating macOS from 26.5.1 to 26.6.2 did not change the result. The original strict-signature failure is currently not reproducible on either tested OS version with the exact original 0.147.0 binary bytes.

Additional current-stable verification:

I also tested the current npm release @openai/codex@0.150.1 on the same Apple Silicon Mac running macOS 26.6.2 (25G83).

Native Codex 0.150.1 arm64 SHA-256:

a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b

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

valid on disk

satisfies its Designated Requirement

with:

codesign_exit=0

The entitlements decode successfully and contain the same JIT / unsigned-executable-memory entitlements.

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

rejected (the code is valid but does not seem to be an app)

with spctl_exit=3.

I first installed 0.150.1 into an isolated local npm test directory, verified the above native binary, then upgraded the normal global Codex installation. The global native binary has the exact same SHA-256:

a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b

and also passes strict codesign verification.

For reproducibility, I preserved byte-for-byte copies of both native binaries:

• Codex 0.147.0 arm64:

19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37

• Codex 0.150.1 arm64:

a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b

At this point, both the original 0.147.0 bytes and current 0.150.1 bytes pass strict signature verification on this host. I still do not know what changed between the original failing 0.147.0 verification and the later successful re-tests, so I am leaving the issue open pending maintainer guidance or a confirmed root cause.

Update: reproducible strict-codesign failure on Codex 0.150.1 Darwin ARM64

I’m adding a new point-in-time observation for Codex CLI 0.150.1. This does not replace or invalidate the historical 0.147.0 evidence already reported in this issue.

Historical 0.147.0 context remains unchanged

Preserved historical executable:

$HOME/Codex-37725-preserved/codex-0.147.0-arm64

SHA-256:

19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37

I rechecked that hash during the current diagnostic. The 0.147.0 executable was not executed and the historical experiment was not repeated.

THE FAILURE OCCURRED AND WAS OBSERVED ON THE PRESERVED EXACT BYTES; IT LATER BECAME NOT REPRODUCIBLE ON THOSE SAME BYTES; ROOT CAUSE REMAINS UNRESOLVED.

I am not asserting that OpenAI fixed or failed to fix the historical issue, and I am not asserting that the historical 0.147.0 and current 0.150.1 observations have the same root cause.

Current environment

• macOS 26.6.2
• Build 25G83
• arm64
• codex-cli 0.150.1

Active native executable:

$HOME/.nvm/versions/node/v20.20.2/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex

Separately preserved 0.150.1 executable:

$HOME/Codex-37725-preserved/codex-0.150.1-arm64

SHA-256 of both files:

a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b

A direct byte comparison returned:

cmp_exit=0

Therefore, the active and preserved 0.150.1 executables are byte-for-byte identical.

Strict-verification reproducibility

I ran the following command exactly three times against each file—six strict-verification attempts total:

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

The six attempts were performed between:

2026-08-27T15:07:27.224816Z
2026-08-27T15:07:27.922742Z

Every attempt had empty stdout and returned:

invalid signature (code or signature have been modified)
In architecture: arm64

Every attempt returned:

codesign_exit=1

The SHA-256 was re-established as a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b for each target during the matrix.

Current classification:

CURRENT 0.150.1 STRICT_CODESIGN FAILURE — REPRODUCIBLE ON ACTIVE AND PRESERVED IDENTICAL BYTES

There was no alternating result against the same path and no different result between the active and preserved paths.

Signing metadata

codesign -d --verbose=4 returned identical metadata for both files after normalizing only the executable path:

• Identifier: codex
• TeamIdentifier: 2DC432GLL2
• Format: Mach-O thin arm64
• CodeDirectory: v=20500
• CodeDirectory flags: 0x10000(runtime)
• CodeDirectory location: embedded
• Signature size: 9046
• CDHash: fdfd262db13f3dc9f45e23399163f9a8d642a966
• Candidate CDHash full SHA-256: fdfd262db13f3dc9f45e23399163f9a8d642a966fdfbd00a765ca424d2c3da11
• CMS digest: fdfd262db13f3dc9f45e23399163f9a8d642a966fdfbd00a765ca424d2c3da11
• Runtime version: 15.5.0
• Info.plist: not bound
• Sealed resources: none
• Internal requirements: count 1, size 168

The designated requirement was also identical:

identifier codex and anchor apple generic and
certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and
certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and
certificate leaf[subject.OU] = "2DC432GLL2"

However, both copies reported:

Authority=(unavailable)

Therefore, the expected leaf authority:

Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

was not freshly observable from codesign during this failed state. I am not claiming that a different signer was observed; the authority-chain information was unavailable.

No Timestamp= field was present in the displayed metadata, so timestamp information was also unavailable from this inspection.

Entitlements

For both files, entitlement extraction returned exit 0 but no entitlement bytes and emitted:

warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.

The extracted stdout was empty for both files. Independent plist parsing failed for both with an invalid-file result, so no entitlement keys could be established.

The two entitlement results were identical. The invalid entitlements blob appears to be a significant observable characteristic that may help diagnosis, but I have not established that it causes the strict-verification failure.

spctl secondary evidence

The following command was run once against each copy:

spctl --assess --type execute --verbose=4 <target>

Both assessments returned empty stdout and:

internal error in Code Signing subsystem

Both returned exit 1.

I am treating this only as secondary, inconclusive evidence. I am not classifying it as STANDALONE_SIGNATURE_INVALID, and it does not override the direct strict-codesign result.

Filesystem and metadata comparison

Both copies are non-symlink regular files and have:

• the same size;
• the same owner and group;
• mode 0755;
• link count 1;
• no file flags;
• no ACL;
• no extended attributes;
• no com.apple.quarantine;
• no com.apple.provenance.

They are separate filesystem objects with different paths, inodes, and timestamps, but both exhibit the same strict-verification failure.

Within this bounded comparison, I found no evidence that the result depends on:

• PATH selection;
• active-versus-preserved byte differences;
• quarantine or provenance xattrs;
• other xattrs;
• ACLs;
• ownership;
• mode;
• file flags;
• the active versus preserved path.

Questions

Could OpenAI please clarify, if possible:

1. Is the official Codex 0.150.1 Darwin ARM64 native executable corresponding to SHA-256

a14f9a907c12c8812878b70e6b7d65f81c39ed795513e46a55817d7428c0ca6b

expected to pass:

codesign --verify --strict --verbose=4?

1. Can OpenAI reproduce the strict-verification failure against that exact release artifact?

1. Is the warning

binary contains an invalid entitlements blob. The OS will ignore these entitlements.

expected for this artifact?

1. Is Authority=(unavailable) expected for the distributed binary in this state?

1. Is there an authoritative OpenAI SHA-256 and signing attestation for the Darwin ARM64 Codex 0.150.1 release artifact?

1. Is there any additional read-only diagnostic OpenAI recommends collecting?

I have not re-signed or modified either binary, removed quarantine, disabled Gatekeeper, changed macOS security settings, applied an ad-hoc signature, replaced the active executable, or attempted another signature workaround.

The current root cause remains unresolved.