macOS arm64 Codex executable in npm SDK artifacts fails code-signature verification

macOS arm64 Codex executable in npm SDK artifacts fails code-signature verification

Summary

Official npm-integrity-verified macOS arm64 runtime artifacts used by
@openai/codex-sdk contain a Codex executable that fails strict macOS
code-signature verification.

This was reproduced with @openai/codex-sdk@0.78.0 and
@openai/codex-sdk@0.146.0. With 0.78.0, macOS AMFI/Gatekeeper
blocked the executable before the SDK emitted thread.started. The 0.146.0
darwin-arm64 executable was not run; a provider-free integrity/signing probe
showed that it fails the same strict signature check.

The observed defect is localized to the packaged macOS executable and
process-start boundary. This report does not claim that the SDK's higher-level
thread, structured-output, or provider logic is defective.

Environment

• macOS on Apple Silicon (arm64)
• Node.js v25.8.2
• Tested SDK versions: 0.78.0, 0.146.0
• Code-signing check:
  codesign --verify --strict --verbose=4 <binary>
• Provider/API credentials are not required to reproduce the signature failure.

Affected versions tested

@openai/codex-sdk@0.78.0

• Lockfile/cache integrity: verified
• npm integrity:
  sha512-sKASs6a5mqR7haOtyTETm+a72dZLLxIYGfMwiJiLGI/xDJyABV0UYQ2V0rvGxG+MPj5ndH+pef6S2BZKpftTiA==
• Installed arm64 executable:
  vendor/aarch64-apple-darwin/codex/codex
• Installed executable SHA-256:
  f9d17cbc360c31c284ed7371588155e018b25342f68d7aee2b994ff0ceefa421
• Cached package-member SHA-256:
  f9d17cbc360c31c284ed7371588155e018b25342f68d7aee2b994ff0ceefa421
• Installed and cached hashes match: yes
• Strict code-signature verification: fail
• SDK protocol initialization: blocked before thread.started
• Provider/model calls: zero

@openai/codex-sdk@0.146.0

The 0.146.0 SDK declares an exact dependency on @openai/codex@0.146.0. On
macOS arm64, that runtime selects the npm alias resolving to
@openai/codex@0.146.0-darwin-arm64 and the SDK resolves:

vendor/aarch64-apple-darwin/bin/codex

• SDK npm integrity: verified
  • sha512-lhlcfmufd4EvjquERH3HNG0/fuxPQJBjFsAjtP2LJjAsuyMZk245ci8xfvT4QoZ7Vnbe15y7rj/NtMNcUJIJOg==
• Runtime-wrapper npm integrity: verified
  • sha512-yG3sPWNda/2YAIQIDq9MrrjoCTIQ7rxYM5IasrG3VBcuhCLTkgeg/JzqmJq1V98RE4MJ5jCxDXXQlOjrditFRw==
• Darwin-arm64 runtime npm integrity: verified
  • sha512-nb61yX4r5L6Z0dlC4o3u0GAK1YCd4TUvjaB382bajDoh84V+uv2hTBIVZ++fgXWV9yoeuNrNnNcn7GoTGOe2Tg==
• Architecture: Mach-O 64-bit executable arm64
• Runtime executable SHA-256:
  ae1d3ffe6d48aec6a4dc3f50e7eb8e0d11962485a6a9406c5a7012139383da02
• Strict code-signature verification: fail
• Codex executable run: no
• Provider/model calls: zero

Reproduction

The signature failure can be reproduced without instantiating the SDK, running
Codex, or making an API/provider call.

1. Read the official npm registry metadata for:
   • @openai/codex-sdk@0.146.0
   • @openai/codex@0.146.0
   • @openai/codex@0.146.0-darwin-arm64
2. Download only the three tarballs named by their dist.tarball fields.
3. For each tarball, calculate SHA-512 and verify that its SRI representation
   equals the corresponding dist.integrity value.
4. From the darwin-arm64 archive, extract only:
   package/vendor/aarch64-apple-darwin/bin/codex
5. Confirm its architecture and digest:

file package/vendor/aarch64-apple-darwin/bin/codex
shasum -a 256 package/vendor/aarch64-apple-darwin/bin/codex

Observed:

Mach-O 64-bit executable arm64
ae1d3ffe6d48aec6a4dc3f50e7eb8e0d11962485a6a9406c5a7012139383da02

6. Verify the embedded signature without executing the binary:

codesign --verify --strict --verbose=4 \
  package/vendor/aarch64-apple-darwin/bin/codex

Observed:

package/vendor/aarch64-apple-darwin/bin/codex: invalid signature (code or signature have been modified)
In architecture: arm64

The command exits with status 1.

Expected behavior

The official npm-integrity-verified macOS arm64 runtime should contain an
executable whose embedded signature passes strict local verification, allowing
the SDK child process to start and emit its initial protocol event.

Actual behavior

Both tested arm64 executables fail strict signature verification. During the
0.78.0 SDK smoke attempt, macOS blocked the child before thread.started; the
SDK surfaced only:

Error: Codex Exec exited with code null:

No SDK thread ID or structured Builder result existed, and no provider/model
call occurred.

Evidence

Confirmed

• All tested package artifacts match their recorded official npm integrity
  metadata.
• In 0.78.0, the installed executable is byte-for-byte identical to the
  matching executable member in the lockfile-integrity-verified npm cache
  artifact.
• The selected macOS arm64 executables from both 0.78.0 and 0.146.0 fail
  codesign --verify --strict --verbose=4.
• macOS AMFI recorded the 0.78.0 executable as invalid at process start:

The signature on the file is invalid
Broken signature with Team ID fatal.

• The 0.78.0 process was blocked before SDK protocol initialization and before
  thread.started.
• Upgrading from 0.78.0 to 0.146.0 would not resolve this established
  signature-verification problem.

Not established

• Why the published artifacts contain executable bytes inconsistent with the
  embedded signature.
• Whether every macOS installation is affected.
• Whether a separately distributed official Codex executable is unaffected.
• Whether higher-level SDK structured-output and controller integration works
  once a valid executable is available.

Hypotheses requiring maintainer confirmation

• A packaging or release step may be changing the executable after signing.
• The embedded signature may be generated before the final npm runtime artifact
  is assembled.
• A macOS-version- or distribution-path-specific condition may contribute to
  the failure.

These are hypotheses only; the collected evidence does not select among them.

Impact

On the affected system, the npm-distributed macOS arm64 executable cannot cross
the local process-start integrity boundary. As a result:

• the SDK cannot initialize a thread;
• thread.started and the SDK thread ID are unavailable;
• structured output cannot be requested or validated;
• higher-level adapter/controller behavior cannot be evaluated against the live
  SDK boundary.

Gatekeeper/AMFI bypass and local re-signing were intentionally not tested; the
goal was to determine whether the official npm-distributed executable passes
normal macOS integrity checks.

Security / integrity note

This report does not assert malware, compromise, or malicious modification.
npm SRI verification and macOS code-signature verification establish different
properties: the former confirms that the downloaded tarball matches registry
metadata, while the latter checks the executable against its embedded macOS
signature. The evidence establishes that the failing executable bytes are
already present in the registry-integrity-matching artifacts; it does not
establish why.

Questions for maintainers

1. Is this a known packaging/signing issue for npm-distributed macOS arm64 Codex
   runtimes?
2. Is there an officially supported workaround that does not weaken
   Gatekeeper/AMFI or locally re-sign the binary?
3. Is there a known-good SDK/runtime version or separately distributed official
   executable that the SDK can safely use?
4. Should the SDK expose child-process termination signals and stderr/security
   failures more explicitly when the CLI is killed before protocol
   initialization?

Start by reproducing the reported extraction and codesign --verify --strict --verbose=4 failure for @openai/codex@0.146.0-darwin-arm64, using vendor/aarch64-apple-darwin/bin/codex. Then trace the npm runtime packaging and release-signing steps for the @openai/codex-sdk and @openai/codex artifacts. Done means the published macOS arm64 executable passes strict local signature verification and can cross the SDK process-start boundary.