macOS Sequoia 15.7.1 quarantine kills codex binary until xattr is cleared

as a workaround i ran

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

to fix the issue.

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

@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

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".

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

@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.

@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.

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.

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!

@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]

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!

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.

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.

@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)

<img width="255" height="294" alt="Image" src="https://github.com/user-attachments/assets/efabb768-4a49-4fe5-9d18-4d312bc25d8e" />

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

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)

@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)

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

@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

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 🙏

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

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