[Bug] macOS brew upgrade requires bypassing security to launch Claude Code

👀

<img width="265" height="267" alt="Image" src="https://github.com/user-attachments/assets/12362a37-89f8-4337-978c-ce556214f9a9" />

hey claude-code/anthropic team, should we be worried?

i experienced the same after upgrading with:

brew upgrade --cask claude-code

even after manually deleting the existing claude app from applications:

sudo rm -rf /Applications/Claude.app

uninstalling claude-code cask with "force" to ensure full cleanup:

brew uninstall --force --cask claude

and finally, installing claude-code fresh again:

brew install --cask claude

environment info:

• platform: darwin (apple silicon)
• macos: macos tahoe
• terminal: warp, ghostty
• claude-code version: 2.0.55

the only thing i haven't done is delete the entire ~/.claude folder.

thanks.

it works as expected now, no more warnings and no need to bypass any security settings. this issue is resolved and can be closed.

p.s.

i ran:

brew reinstall --cask claude-code

ran:

claude

and voilà, no more warnings.

thanks! 🙏

The issue came back on with the 2 latest release....

I just got this issue for the first time, and then ran brew reinstall --cask claude-code and now the issue is gone again.

Any news about this issue?
I have the same issue and reinstall didn't work in my case.

@joseyukio follow the tip in the link from apple support that i linked in the original post.
(The problem seems solved with the last patch though)

And today this happened to me after upgrading to the latest version using brew upgrade.

Try System Settings: Privacy & Security and then scroll down. There should be a warning about Claube being blocked with a button "Allow Anyway"

I've caught this notarization error message just after an upgrade claude-code 2.1.39 -> 2.1.42 by brew upgrade, and fixed the error by running brew reinstall --cask claude-code. I'm not sure why this issue still remains.

Got "Apple could not verify “claude” is free of malware that may harm your Mac or compromise your privacy." with 2.1.47 too.
brew reinstall --cask claude-code not helped but what helped is allow claude in Privacy & Security

what helped is allow claude in Privacy & Security

This is a bit unsafe! You can only do this if you know the source of the binary.

Getting this same error message with version 2.1.80

I encountered this issue when I brew upgrade claude-code v2.1.84 → v2.1.85

Since this has been open for months, I assume I'll get hit again.
My trivial solution: dequarantine.sh claude

any updates?

Just got this issue on an upgrade from 2.1.131 to 2.1.132:

➜  brew upgrade claude-code@latest
==> Auto-updating Homebrew...
Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or disable with
`$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with `$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
==> Auto-updated Homebrew!
==> Updated Homebrew from 0f9224a989 to 29bb419bad.
Updated 2 taps (homebrew/core and homebrew/cask).
==> New Formulae
smlnj: Compiler and programming system for Standard ML
zapp: Flash ZSA keyboards from your terminal
==> New Casks
open-webui: Desktop application for Open WebUI

You have 145 outdated formulae and 3 outdated casks installed.

==> Fetching downloads for: claude-code@latest
✔︎ Cask claude-code@latest (2.1.132)                                  Verified    218.0MB/218.0MB
==> Upgrading 1 outdated package:
claude-code@latest 2.1.131 -> 2.1.132
==> Upgrading claude-code@latest
  2.1.131 -> 2.1.132
==> Unlinking Binary '/opt/homebrew/bin/claude'
==> Linking Binary 'claude' to '/opt/homebrew/bin/claude'
==> Purging files for version 2.1.131 of Cask claude-code@latest
🍺  claude-code@latest was successfully upgraded!
==> Upgraded 1 outdated package
claude-code@latest 2.1.131 -> 2.1.132

Did a re-install just to be safe:

➜  brew reinstall claude-code@latest
==> Fetching downloads for: claude-code@latest
✔︎ Cask claude-code@latest (2.1.132)                                  Verified    218.0MB/218.0MB
==> Uninstalling Cask claude-code@latest
==> Unlinking Binary '/opt/homebrew/bin/claude'
==> Purging files for version 2.1.132 of Cask claude-code@latest
==> Installing Cask claude-code@latest
==> Linking Binary 'claude' to '/opt/homebrew/bin/claude'
🍺  claude-code@latest was successfully installed!

Still hitting this on fresh brew upgrade --cask claude-code for some recent versions (2.1.126). Wrote a small script that verifies the binary against Anthropic's Apple Team ID (Q6L2SF6YDW), then clears com.apple.quarantine only if the signature check passes — so it doesn't blindly bypass Gatekeeper:

https://gist.github.com/dfa1/3cdb171e72f8e1c71c1b47a13f4bbb69

Drop-in usage after each upgrade:

brew upgrade --cask claude-code && verify-claude.sh

Hope it's useful to others until the notarization side gets sorted out.

Thanks for putting this script together @dfa1.
I have 2 questions.

• How did you find found Anthropic's Apple Team ID?
• Is there any material I can read about how common the notarization issue is?

Since this issue has been reported on November last year, I encounter this problem a handful of times, but on every macOS update seems like the quarantine list gets cleaned up or something.

I cannot believe that they have not found a permanent solution for a tool that elicits such a level of autonomy.

How I found the Team ID

It's embedded in the code signature of any signed binary Anthropic ships — not secret. There are 2 ways:

# this is snippet used by the script
$ codesign -dv --verbose=4 $(which claude) 2>&1 | grep TeamIdentifier
TeamIdentifier=Q6L2SF6YDW

# alternatively
$ spctl -a -vv $(which claude)
# → origin=Developer ID Application: Anthropic, PBC (XXXXXXXXXX)

The same TeamId is documented here as well: https://claude.com/docs/cowork/3p/installation?search=how+to+find+the+teamid+for+anthin+apple%3F#endpoint-security-software

On how common the notarization issue is

I don't have a single authoritative source to point at, but the failure pattern is well-known:

• Apple's notarization docs: https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution
• The recurring class of bug is notarized but the ticket isn't stapled, or stapling gets invalidated by post-signing modification (re-compression, re-signing in CI, etc.). When the staple is missing, Gatekeeper has to check online — and that's where things break for offline machines, first launches, or when the com.apple.quarantine xattr handling differs between brew cask and formula installs.
• You'll find similar Gatekeeper-after-brew-upgrade reports across some CLI tools distributed via Homebrew, which is why I'd treat this as a packaging/stapling regression rather than something exotic to Claude Code.

Correcting a common misread in this thread (including my own first take): the claude binary is signed and notarized. That's verifiable:

❯ codesign -dvvvv "$(which claude)"
Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW)
...
flags=0x10000(runtime)

❯ spctl -a -vvv -t install "$(which claude)"
/opt/homebrew/bin/claude: accepted
source=Notarized Developer ID

So this isn't a signing problem, and it's not the "unsigned cask gets deprecated" issue — the cask passes Gatekeeper/notarization checks.

The actual root cause is stapling. claude is shipped as a standalone Mach-O binary, and Apple does not support stapling a notarization ticket to a bare binary (only .app, .pkg, .dmg, .kext can be stapled). Per Apple's own guidance for notarized CLI tools/daemons: with no stapled ticket, Gatekeeper has to fetch the ticket from Apple's notary service over the network on first launch of each build. If the machine is online it downloads and caches the ticket silently; if that check can't complete, you get the "could not verify… Move to Trash" alert.

That explains the contradictory reports here:

• spctl says "Notarized" because that call reaches Apple (or the cache) successfully.
• It appears right after brew upgrade because a new version = new CDHash = the cached ticket no longer applies, so a fresh online check is required.
• It's intermittent across users because it depends on network conditions at launch (offline, captive portal, proxy/firewall, notary latency).
• It surfaced more broadly with recent Homebrew, which keeps the com.apple.quarantine attribute on the binary now that --no-quarantine is gone — putting that online check in the launch path where it effectively wasn't before.

Why this matters for managing Claude Code via Homebrew: every release ships a new CDHash, so every brew upgrade re-triggers the online notarization check. On any machine that's offline, behind a locked-down proxy, in CI, or under MDM, that check fails and a human has to click "Allow Anyway" through a GUI security prompt — which defeats unattended brew upgrade --cask and fleet workflows entirely.

The fix is on the Anthropic side and is the standard remedy for notarized CLI tools: distribute the binary inside a notarized and stapled .pkg (or .dmg) rather than as a bare Mach-O. A stapled container carries a local ticket, so Gatekeeper verifies offline and the runtime network dependency goes away. Homebrew casks consume .pkg/.dmg artifacts without issue.

Environment:

• Claude Code: 2.1.173 (Claude Code) (claude-code@latest cask)
• Homebrew: 6.0.0
• macOS: 26.5.1