Skip to content

macOS Sequoia 15.7.1 quarantine kills codex binary until xattr is cleared #5787

Closed
Closed
macOS Sequoia 15.7.1 quarantine kills codex binary until xattr is cleared#5787
Labels
CLIIssues related to the Codex CLIbugSomething isn't working

Description

@JeffreyArt1
JeffreyArt1
opened on Oct 26, 2025

What version of Codex is running?

v0.50.0

What subscription do you have?

Plus

Which model were you using?

No response

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex cant open and gets closed with a notice that the app is damaged.

Upon investigation i found gatekeeper put it in quarantine.

$> codex       
[1]    35571 killed     codex
$> which codex                                        
/opt/homebrew/bin/codex
$> xattr /opt/homebrew/bin/codex                          
com.apple.metadata:kMDItemAlternateNames
com.apple.provenance
com.apple.quarantine

What steps can reproduce the bug?

Uploaded thread: 019a22a3-65e6-7521-b77a-4b6eb7855243

What is the expected behavior?

No response

Additional information

No response

Activity

  1. JeffreyArt1
    added
    bugSomething isn't working
    on Oct 26, 2025

  2. JeffreyArt1 commented on Oct 26, 2025

    @JeffreyArt1
    JeffreyArt1
    on Oct 26, 2025
    Author

    as a workaround i ran

    sudo xattr -d com.apple.quarantine /opt/homebrew/bin/codex

    to fix the issue.

  3. bolinfest commented on Oct 28, 2025

    @bolinfest
    bolinfest
    on Oct 28, 2025
    Collaborator

    @JeffreyArt1 so you installed Codex via brew (as opposed to downloading it from GitHub Releases or some other mechanishm?)

  4. JeffreyArt1 commented on Oct 28, 2025

    @JeffreyArt1
    JeffreyArt1
    on Oct 28, 2025
    Author

    @JeffreyArt1 so you installed Codex via brew (as opposed to downloading it from GitHub Releases or some other mechanishm?)

    Yeah, i had it installed. The issue was with this particular version. I upgraded from a previous version using brew upgrade codex

  5. dsumpter commented on Nov 4, 2025

    @dsumpter
    dsumpter
    on Nov 4, 2025

    Adding to this. I tried installing via both brew and npm. macOS Tahoe 26.0.1 quarantined which I believe also triggered a block by Jamf Protect (in corporate environment). I was not able to use the suggested xattr solution above. Workaround for me was to uninstall and go back to the last known working version by running "npm install -g @openai/codex@0.46.0".

  6. JeffreyArt1 commented on Nov 7, 2025

    @JeffreyArt1
    JeffreyArt1
    on Nov 7, 2025
    Author

    Adding to this. I tried installing via both brew and npm. macOS Tahoe 26.0.1 quarantined which I believe also triggered a block by Jamf Protect (in corporate environment). I was not able to use the suggested xattr solution above. Workaround for me was to uninstall and go back to the last known working version by running "npm install -g @openai/codex@0.46.0".

    Can you try with the latest version? v0.55.0

  7. dsumpter commented on Nov 7, 2025

    @dsumpter
    dsumpter
    on Nov 7, 2025

    @JeffreyArt1 I experience the same with v0.55.0. Note I worked with a different coding agent to troubleshoot why 0.46.0 works but not 0.55.0 and got the following:

    Version 0.46.0 (working):

    • Uses adhoc signature (essentially unsigned)
    • No hardened runtime
    • macOS allows it because it doesn't claim to be a properly signed app

    Version 0.55.0 (blocked):

    • Properly signed with Developer ID certificate from OpenAI
    • Has hardened runtime enabled
    • NOT notarized - missing Apple's notarization ticket
    • This triggers stricter Gatekeeper enforcement

    OpenAI improved their security by adding proper code signing to 0.55.0, but forgot to notarize it. Since it's signed with a Developer ID but lacks notarization, macOS blocks it more aggressively than the unsigned 0.46.0 version.

  8. JeffreyArt1 commented on Nov 7, 2025

    @JeffreyArt1
    JeffreyArt1
    on Nov 7, 2025
    Author

    @JeffreyArt1 I experience the same with v0.55.0. Note I worked with a different coding agent to troubleshoot why 0.46.0 works but not 0.55.0 and got the following:

    Version 0.46.0 (working):

    • Uses adhoc signature (essentially unsigned)
    • No hardened runtime
    • macOS allows it because it doesn't claim to be a properly signed app

    Version 0.55.0 (blocked):

    • Properly signed with Developer ID certificate from OpenAI
    • Has hardened runtime enabled
    • NOT notarized - missing Apple's notarization ticket
    • This triggers stricter Gatekeeper enforcement

    OpenAI improved their security by adding proper code signing to 0.55.0, but forgot to notarize it. Since it's signed with a Developer ID but lacks notarization, macOS blocks it more aggressively than the unsigned 0.46.0 version.

    That makes a lot of sense! I can see that they are working towards fixing it(?) thanks for the info.

  9. shijie-oai commented on Nov 7, 2025

    @shijie-oai
    shijie-oai
    on Nov 7, 2025
    Contributor

    Thanks for flagging - just checked and we added notarization step but it seems like we did not staple the notarization ticket to the binary itself which can cause failed check in certain situations. Sorry about the inconvenience and I will address this.

  10. JaviSoto commented on Nov 7, 2025

    @JaviSoto
    JaviSoto
    on Nov 7, 2025
    Contributor

    Hi @JeffreyArt1!

    We just spent some time looking into this and we can't find anything wrong with the binaries we're distributing via homebrew. They are correctly notarized. They are not stapled because plain binaries cannot be stapled, only packages such as dmg of app bundles can be. But stapling just allows macOS to skip "phoning home" to Apple to verify the notarization, so it's totally optional and given that you can't staple a binary, expected.

    Our hypothesis is that you may have an MDM profile on your machine that's enabling some stricter macOS Gatekeeper rules that lead to the binary being rejected.

    If you wouldn't mind, would you be willing to run a few commands on your terminal so we can gather some more info and see if we can find the root-cause and a workaround?

    # Sanity-check the file signature to make sure nothing else has messed with the file
shasum -a 256 $(which codex)

# Ask Gatekeeper what it thinks about the binary
spctl --assess --type execute -vv $(which codex)

# Check code-signing
codesign -dv --verbose=4 $(which codex)

    Besides that, if you run this in a terminal tab right before you run codex in another to reproduce the crash ([1] 35571 killed codex), we'll be able to see exactly the reason why macOS is rejecting it:

    log stream --style syslog --predicate 'subsystem == "com.apple.security.syspolicy" || category == "SecAssessment"' --info

    After you repro it, do ctrl+c on that log stream, and see if you find something in the logs like:

    SecAssessment: rejected <reason>
Policy: disallowed by configuration profile
Gatekeeper: refusing unnotarized executable at path … 

    Hopefully we can get this fixed for you 🙏 thank you for your patience!

  11. dsumpter commented on Nov 7, 2025

    @dsumpter
    dsumpter
    on Nov 7, 2025

    @JaviSoto It looks like macOS gatekeeper is no longer quarantining codex cli, however Jamf Protect is still blocking it (for me and other people in my org). I can provide outputs from the commands, but note the log stream command returns nothing because it is now just Jamf Protect removing codex and killing the process. Here are the outputs:

    ➜  personal_scratch git:(main) ✗ npm uninstall -g @openai/codex
removed 1 package in 176ms
➜  personal_scratch git:(main) ✗ brew install --cask codex
==> Downloading https://github.com/openai/codex/releases/download/rust
Already downloaded: /Users/dsumpter/Library/Caches/Homebrew/downloads/769f50af6021c5a7a9582db63970a32b728fc4365aea65571507ca9c856cf765--codex-aarch64-apple-darwin.tar.gz
All dependencies satisfied.
==> Installing Cask codex
==> Linking Binary 'codex-aarch64-apple-darwin' to '/opt/homebrew/bin/
🍺  codex was successfully installed!
➜  personal_scratch git:(main) ✗ shasum -a 256 $(which codex)
3c1b1f0769af9b227b2cbf01f9e96fb8ea7f7f0df7baeb7941f6426f2e61876a  /opt/homebrew/bin/codex
➜  personal_scratch git:(main) ✗ spctl --assess --type execute -vv $(which codex)
/opt/homebrew/bin/codex: rejected (the code is valid but does not seem to be an app)
origin=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)
➜  personal_scratch git:(main) ✗ codesign -dv --verbose=4 $(which codex)
Executable=/opt/homebrew/Caskroom/codex/0.55.0/codex-aarch64-apple-darwin
Identifier=codex
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=273937 flags=0x10000(runtime) hashes=8555+2 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=984320
Hash type=sha256 size=32
CandidateCDHash sha256=a43e9adc24181ad1b636015d4ca334544e249e4e
CandidateCDHashFull sha256=a43e9adc24181ad1b636015d4ca334544e249e4e3ff8c7091cf290ac764ce4cb
Hash choices=sha256
CMSDigest=a43e9adc24181ad1b636015d4ca334544e249e4e3ff8c7091cf290ac764ce4cb
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=33914880
Executable Segment flags=0x1
Page size=4096
CDHash=a43e9adc24181ad1b636015d4ca334544e249e4e
Signature size=9048
Authority=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Nov 4, 2025 at 12:08:26 PM
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Runtime Version=15.5.0
Sealed Resources=none
Internal requirements count=1 size=168
➜  personal_scratch git:(main) ✗ log stream --style syslog --predicate 'subsystem == "com.apple.security.syspolicy" || category == "SecAssessment"' --info
Filtering the log data using "subsystem == "com.apple.security.syspolicy" OR category == "SecAssessment""
^CTimestamp                       (process)[PID]

  12. JaviSoto commented on Nov 7, 2025

    @JaviSoto
    JaviSoto
    on Nov 7, 2025
    Contributor

    Gotcha thank you that's very helpful!!!
    You might be able to get some info by running log stream --style syslog --predicate 'subsystem CONTAINS "jamf" OR process CONTAINS "jamf"' --info, but I think you may need to ask your IT department about this, as it seems it's some policy they have enabled on your laptop that's causing this. If it's something we're doing that's tripping Jamf Protect for you folks, let us know cause we'd love to make it better!

  13. JeffreyArt1 commented on Nov 12, 2025

    @JeffreyArt1
    JeffreyArt1
    on Nov 12, 2025
    Author

    Hi @JeffreyArt1!

    We just spent some time looking into this and we can't find anything wrong with the binaries we're distributing via homebrew. They are correctly notarized. They are not stapled because plain binaries cannot be stapled, only packages such as dmg of app bundles can be. But stapling just allows macOS to skip "phoning home" to Apple to verify the notarization, so it's totally optional and given that you can't staple a binary, expected.

    Our hypothesis is that you may have an MDM profile on your machine that's enabling some stricter macOS Gatekeeper rules that lead to the binary being rejected.

    If you wouldn't mind, would you be willing to run a few commands on your terminal so we can gather some more info and see if we can find the root-cause and a workaround?

    Sanity-check the file signature to make sure nothing else has messed with the file

    shasum -a 256 $(which codex)

    Ask Gatekeeper what it thinks about the binary

    spctl --assess --type execute -vv $(which codex)

    Check code-signing

    codesign -dv --verbose=4 $(which codex)
    Besides that, if you run this in a terminal tab right before you run codex in another to reproduce the crash ([1] 35571 killed codex), we'll be able to see exactly the reason why macOS is rejecting it:

    log stream --style syslog --predicate 'subsystem == "com.apple.security.syspolicy" || category == "SecAssessment"' --info
    After you repro it, do ctrl+c on that log stream, and see if you find something in the logs like:

    SecAssessment: rejected <reason>
Policy: disallowed by configuration profile
Gatekeeper: refusing unnotarized executable at path … 

    Hopefully we can get this fixed for you 🙏 thank you for your patience!

    Hi @JaviSoto!

    I ended up installing v0.51.0, and the issues went away. I periodically upgrade the package via brew and haven’t seen the issue since.

    I’m not sure if that’s enough to close this issue since it’s working fine for me now, but I noticed a few other comments mentioning similar problems.

  14. etraut-openai commented on Nov 12, 2025

    @etraut-openai
    etraut-openai
    on Nov 12, 2025
    Contributor

    Thanks for confirming the fix. I'm going to close the issue under the assumption that the problem has been addressed. If anyone sees the problem again with the latest version of codex, let us know.

  15. etraut-openai
    closed this as completedon Nov 12, 2025

  16. dsumpter commented on Nov 12, 2025

    @dsumpter
    dsumpter
    on Nov 12, 2025

    @etraut-openai and @JaviSoto I tried installing latest codex version to see if anything has changed. I am back to getting codex blocked by macOS gatekeeper (in addition to Jamf)

    Image

    I suspect I stopped getting blocked by gatekeeper because I removed the quarantine attribute in the prior version (following advice above), but installing the latest version means quarantine attribute is present again:

    xattr -l /opt/homebrew/Caskroom/codex/0.57.0/codex-aarch64-apple-darwin
com.apple.metadata:kMDItemAlternateNames: ("codex")
com.apple.provenance:
com.apple.quarantine: 0381;6914cd91;;99C10DD6-42A9-46C2-82C9-71DF7DF1BAE8

    Here are the diagnostics output, I think most pertinent is that spctl --assess now says that source=Unnotarized Developer ID.:

      ~ brew install --cask codex
==> Downloading https://github.com/openai/codex/releases/download/rust-v0.57.0/codex
Already downloaded: /Users/dsumpter/Library/Caches/Homebrew/downloads/67e924054b2e7be57cbf530f0b9b2501e4f25105b6f66004bcdc0f64fbae257c--codex-aarch64-apple-darwin.tar.gz
All dependencies satisfied.
==> Installing Cask codex
==> Linking Binary 'codex-aarch64-apple-darwin' to '/opt/homebrew/bin/codex'
🍺  codex was successfully installed!
➜  ~ shasum -a 256 $(which codex)
3bec90a42132000f5efe62ec9659dcb6171248d01c68e44efa451220fa8b9653  /opt/homebrew/bin/codex
➜  ~ spctl --assess --type execute -vv $(which codex)
/opt/homebrew/bin/codex: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)
➜  ~ codesign -dv --verbose=4 $(which codex)
Executable=/opt/homebrew/Caskroom/codex/0.57.0/codex-aarch64-apple-darwin
Identifier=codex
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=279217 flags=0x10000(runtime) hashes=8720+2 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=984320
Hash type=sha256 size=32
CandidateCDHash sha256=b196cbe09f3882f0e874e75466d30bc2b73d57ce
CandidateCDHashFull sha256=b196cbe09f3882f0e874e75466d30bc2b73d57ce7d5067acc03853605d40c65c
Hash choices=sha256
CMSDigest=b196cbe09f3882f0e874e75466d30bc2b73d57ce7d5067acc03853605d40c65c
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=34586624
Executable Segment flags=0x1
Page size=4096
CDHash=b196cbe09f3882f0e874e75466d30bc2b73d57ce
Signature size=9049
Authority=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Nov 9, 2025 at 2:15:16 PM
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Runtime Version=15.5.0
Sealed Resources=none
Internal requirements count=1 size=168
  17. etraut-openai
    reopened this on Nov 12, 2025

  18. JaviSoto commented on Nov 12, 2025

    @JaviSoto
    JaviSoto
    on Nov 12, 2025
    Contributor

    but installing the latest version means quarantine attribute is present again:

    That is entirely expected for any binary you download from the internet. I see that here as well, but I'm able to run codex because the first time macOS tries to run a quarantined app it checks the notarization.
    You ran spctl --assess --type execute -vv $(which codex) but I gave you the wrong command, the right one for bare executables would be:

    spctl --assess --type install -vv $(which codex)

    Can you share what that outputs? 🙏

    I ran that on the last 5 releases of codex and this is what I see:

    spctl --assess --type install -vv /opt/homebrew/bin/codex
/opt/homebrew/bin/codex: accepted
source=Notarized Developer ID
origin=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)

  19. dsumpter commented on Nov 12, 2025

    @dsumpter
    dsumpter
    on Nov 12, 2025

    @JaviSoto This is what I see

    ➜  ~ spctl --assess --type install -vv $(which codex)
/opt/homebrew/bin/codex: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: OpenAI, L.L.C. (2DC432GLL2)

  20. JaviSoto commented on Nov 12, 2025

    @JaviSoto
    JaviSoto
    on Nov 12, 2025
    Contributor

    Thank you for bearing with me 🙏 hopefully we can figure this out. That is very strange. Can you try these?

    # Print spctl’s internal reason codes
spctl --assess --type install -vv --ignore-cache --raw $(which codex)

# Pull the Gatekeeper assessment log for that binary
log show --last 5m --style syslog --predicate 'subsystem == "com.apple.security.assessment" && eventMessage CONTAINS "codex"' | tail -n 50

# Check if any profile is changing gatekeeper's behavior
profiles show -type configuration | grep -i -A2 -B2 gatekeeper

  21. dsumpter commented on Nov 12, 2025

    @dsumpter
    dsumpter
    on Nov 12, 2025

    @JaviSoto I believe I identified the culprit - the call to notary.apple.com. TLS Inspection breaks the call (normally not an issue but looks like notary.apple.com is more sensitive to this). If true resolution options are:

    1. I ask to get notary.apple.com whitelisted so its not subject to TLS Inspection. This would need to be done by any company using TLS Inspection (if they identify it as the culprit).
    2. Codex is distributed in another format (than tar.gz) that allows stapling so gatekeeper does not need to call home. This would be my personal hope, but unsure about the complexity of switching formats.

    Evidence:

    ➜  ~ log show --predicate 'process == "syspolicyd"' --last 1h | grep -i notar

2025-11-12 12:13:52.833411-0800 0x46a7bb   Default     0x0                  675    0    syspolicyd: (Security) [com.apple.securityd:SecError] Error checking with notarization daemon: 3
    ➜  ~ curl -v https://notary.apple.com

* Could not resolve host: notary.apple.com
* Closing connection
curl: (6) Could not resolve host: notary.apple.com

  22. JaviSoto commented on Nov 12, 2025

    @JaviSoto
    JaviSoto
    on Nov 12, 2025
    Contributor

    Ah yeah, MiTM-ing Apple's requests is gonna be an issue :D I'm surprised it doesn't cause problems with more programs!

    We will look into the feasibility of distributing a stapled package. Thanks a lot for working on this with me though so we could get to the root-cause! That was super helpful 🙏

  23. etraut-openai
    added
    CLIIssues related to the Codex CLI
    on Nov 15, 2025

  24. celia-oai commented on Dec 18, 2025

    @celia-oai
    celia-oai
    on Dec 18, 2025
    Contributor

    We added stapled dmg target in this PR: #8207. Hope this helps!

  25. celia-oai
    closed this as completedon Dec 18, 2025

  26. SC-CTS commented on Dec 19, 2025

    @SC-CTS
    SC-CTS
    on Dec 19, 2025

    Would be amazing if the homebrew cask was updated to use the stapled dmg then so updates don't break the binary constantly: https://github.com/Homebrew/homebrew-cask/blob/main/Casks/c/codex.rb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions