App blocked: "Apple cannot check it for malicious software"

After this, the app opens normally and macOS remembers your decision — you won't be asked again for that specific file.

Why this happens

Gatekeeper checks every downloaded app against two things: whether it's signed by a known Apple Developer ID, and whether Apple has notarized it (scanned it and issued a ticket). Anything downloaded through a GUI app — a browser, a mail client — gets a com.apple.quarantine attribute attached, which is what triggers the check the first time you open it; tools like curl deliberately don't attach it, which is by design, not a loophole. If either check fails, you get this message instead of a normal "unidentified developer" warning. It's the same quarantine mechanism whether the app is legitimate-but-unsigned or actually something to avoid — macOS doesn't distinguish in the message, you have to make that call based on where the file came from.

On Apple Silicon specifically, there's a hard OS-level rule Intel Macs never had: native arm64 code will not execute at all without at least an ad-hoc signature — the kernel kills it on launch. Intel (x86_64) code running under Rosetta could get away with no signature whatsoever. That's one reason unsigned indie and open-source tools trip this warning more often on Apple Silicon than the same tool did on an old Intel Mac.

If you remember right-clicking (or Control-clicking) the app and choosing "Open" as a bypass — that stopped working in macOS Sequoia (15). Current macOS removed the contextual-menu override entirely; System Settings → Privacy & Security is now the only path, and it's why step 1 below doesn't mention right-clicking at all.

Fix it

1. Try the interface path first: System Settings → Privacy & Security, scroll down — if you attempted to open the app in the last hour, an "Open Anyway" button is sitting there next to its name. Click it, confirm with "Open" on the dialog that follows, and authenticate if asked. This is the normal, intended way to override the block for something you trust, and it doesn't touch anything outside that one app. It only works within roughly an hour of the blocked attempt — if it's gone, try opening the app again first to re-trigger it.

2. If you want to see what Gatekeeper actually thinks of a specific app before deciding, assess it directly:

   ● Reads the system

   What it does: prints whether Gatekeeper accepts the app, and why.

   After: nothing changes, this only reads.

   spctl --assess --verbose "/Applications/Example.app"

   Copy

   Output — a notarized app (healthy case, captured live)

   /Applications/Example.app: accepted
   source=Notarized Developer ID

   Output — a blocked app (representative, not from this machine)

   /Applications/Example.app: rejected
   source=No usable signature

   The first block was captured live on the verification machine against a real installed, notarized app, to show the accepted format. The second is representative of what a rejected result looks like, since demonstrating an actual rejection would mean installing something intentionally unsigned.

3. If you're confident about the source and want to skip the dialog entirely for that one file, clearing its quarantine flag has the same effect as clicking "Open Anyway," just from the terminal:

   ▲ Changes settings

   What it does: removes the quarantine attribute from the named app, so Gatekeeper stops flagging that specific file.

   After: the app opens normally from now on; other files are untouched.

   sudo xattr -d com.apple.quarantine "/Applications/Example.app"

   Copy

   Revert: re-download the app to restore its quarantine flag, or run xattr -w com.apple.quarantine "0081;00000000;;" "/Applications/Example.app" to reattach one manually.

   If the app is a loose binary or a bundle with nested helper tools that each carry their own quarantine flag, xattr -d on just the top-level path sometimes isn't enough. sudo xattr -cr "/Applications/Example.app" clears every extended attribute recursively and is the more reliable option for those cases — it's broader than just the quarantine flag, so use the narrower -d version above first. For a .pkg installer specifically rather than an app bundle, assess it with spctl --assess --type install -v /path/to/file.pkg — the default assessment type doesn't apply to installer packages.

Still broken?

• Homebrew or a CLI tool is what's actually being blocked — command-line binaries hit the same Gatekeeper check and are worth ruling out separately from GUI apps.
• Check whether Gatekeeper's policy changed in the current macOS version

Verified on

Related problems

• Invalid active developer path
• What's broken in macOS 26 so far
• The message says the app is damaged instead of unidentified