CLI binary releases not notarized — blocks Homebrew Cask distribution #23366

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   on May 18, 2026
2. github-actions commented on May 18, 2026

   

   github-actionsBot

   on May 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • “codex-aarch64-apple-darwin” was not opened because it contains malware. This action did not harm your Mac. #22135

   Powered by Codex Action
3. ardasevinc commented on May 19, 2026

   

   ardasevinc

   on May 19, 2026

   More actions

   oh boy, we need this fixed. switching to npm release for now
4. kim0 commented on May 19, 2026

   

   kim0

   on May 19, 2026

   Last edited by kim0

   More actions

   A bit more diagnostic context that might help whoever picks this up: the regression appears to be specifically from the macOS release pipeline restructure between rust-v0.130.0 and rust-v0.131.0, not just a missed notarization step.

   Evidence — signature diff between the two releases:

   $ codesign -dvv codex-aarch64-apple-darwin   # 0.130
   Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
   Timestamp=9 May 2026 at 1:20:59 AM            ← secure RFC 3161 timestamp from Apple TSA
   Signature size=9053
   
   $ codesign -dvv codex-aarch64-apple-darwin   # 0.131
   Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
   Signed Time=18 May 2026 at 8:43:53 PM         ← local clock only, no Apple TSA
   Signature size=4744
   

   0.131 lost both the secure timestamp and the notarization, which is why spctl flipped from the lenient "the code is valid but does not seem to be an app" on 0.130 to "source=Unnotarized Developer ID" on 0.131 — and that's what the cask CI's signature_verification check rejects.

   Pipeline change that caused it:

   In 0.130, .github/workflows/rust-release.yml ran the macos-code-sign composite action in-CI, which does:

   codesign --force --options runtime --timestamp --entitlements ... --sign $CERT $binary
   xcrun notarytool submit $binary.zip --key ... --wait

   For 0.131, the pipeline was restructured into a two-phase build_unsigned → promote_signed flow (#22559, #22737, #22900) where macOS binaries are signed externally in a secure enclave and re-imported. The promote_signed path only verifies the imported signature — there's no xcrun notarytool submit in it:

   https://github.com/openai/codex/blob/main/.github/workflows/rust-release.yml#L767-L771

   release_path="${dest}/${binary}-${target}"
   ditto "$source_path" "$release_path"
   chmod 0755 "$release_path"
   codesign --verify --strict --verbose=2 "$release_path"   # verify-only

   Two ways to fix:

   1. Have the external signing service also notarize (and use --timestamp against Apple's TSA so the signature gets the secure RFC 3161 timestamp). This is the cleaner fix.
   2. Or, add an xcrun notarytool submit --wait step in the promote_signed job after line 771 (the secrets APPLE_NOTARIZATION_* already exist and are wired up — they just aren't used in this code path).

   Either restores parity with the 0.130 release flow and unblocks Homebrew/cask#264918.
5. kim0 commented on May 19, 2026

   

   kim0

   on May 19, 2026

   More actions

   cc @shijie-oai @bolinfest, flagging since you worked on the build_unsigned/promote_signed restructure (#22737, #22559, #22788, #22900). The notarization gap I described above appears to be a side-effect of that flow change.
6. shijie-oai commented on May 20, 2026

   

   shijie-oai

   on May 20, 2026

   Contributor

   More actions

   @kim0 132 mainline is out - this should reenable homebrew to pick our codex CLI now. Please let us know if there is any more issue at this point.
7. krehel commented on May 20, 2026

   

   krehel

   on May 20, 2026

   More actions

   Homebrew/homebrew-cask#265214 has been merged with version as 0.132.0 - looks to be resolved.

   Thanks all! Appreciate the help!
8. etraut-openai

   closed this as completedon May 20, 2026