Fix macOS Gatekeeper 'App is damaged and can't be opened' Error

You double-click an app you just downloaded and macOS hits you with "App is damaged and can't be opened. You should move it to the Trash." It looks scary. It isn't. In most cases the app isn't damaged at all — Gatekeeper is misreading the quarantine metadata attached to the file. What's actually happening here is that the com.apple.quarantine extended attribute and the app's code signature disagree, and macOS defaults to protecting you.

There are three causes, in order of how often they hit real people. The first one covers easily 80% of cases.

Cause 1: The quarantine flag is stale or mismatched

Every file you download through Safari, Chrome, Firefox, or AirDrop gets tagged with com.apple.quarantine. That flag stores which app downloaded it and when. Gatekeeper checks the flag, then checks the developer's signature against Apple's notarization database. If anything about that handshake looks off — an expired certificate, a download that got interrupted, a DMG that was copied from another Mac — you get the damaged message.

The fix is to strip the quarantine attribute. Open Terminal and run:

xattr -d com.apple.quarantine /Applications/YourApp.app

The reason this works: you're removing the metadata Gatekeeper uses to decide whether to even evaluate the app. Once the flag is gone, the app launches and the code signature is still verified at runtime by the kernel — you're not disabling security, you're just skipping the download-time check that's giving a false positive.

If xattr complains that the attribute doesn't exist, use -c to clear all extended attributes instead:

xattr -cr /Applications/YourApp.app

The -r walks the whole bundle. You need that for apps with frameworks inside — Electron apps like VS Code or Slack, for example. If you only strip the top-level bundle, the helper processes inside will still trip Gatekeeper.

Real scenario: someone AirDrops a DMG from their old Mac to a new one running Sonoma. The receiving Mac sees a quarantine timestamp that predates the app's notarization ticket, and macOS 14's stricter check flags it as damaged. Stripping quarantine takes two seconds.

Cause 2: The code signature is actually broken

Sometimes the app really is damaged — usually because the download was truncated, a third-party unarchiver mangled the permissions, or someone modified the bundle after signing. Before you strip anything, verify the signature. If it's invalid, stop: don't run the app.

codesign --verify --deep --strict --verbose=2 /Applications/YourApp.app

You'll see either valid on disk with satisfies its Designated Requirement, or a specific error. Common ones:

• code object is not signed at all — the developer shipped an unsigned build. Homebrew casks and open-source projects sometimes do this. You'll need to allow it through Privacy & Security.
• resource envelope is obsolete — signature uses an old format macOS no longer trusts. Only the developer can fix this by re-signing.
• a sealed resource is missing or invalid — the bundle was modified after signing. Redownload from the original source.

If codesign reports the app is valid but Gatekeeper still blocks it, check the notarization status with spctl:

spctl --assess --type execute --verbose=4 /Applications/YourApp.app

A source=Notarized Developer ID line means Apple has the ticket. A source=no usable signature or source=Unnotarized Developer ID means you're on your own — the right fix is to right-click the app and choose Open, then click Open in the dialog. On macOS 15 Sequoia, that flow is now in System Settings → Privacy & Security, where a small "Open Anyway" button shows up for the last blocked app.

Cause 3: App translocation is scrambling the path

This one catches people who run apps directly from a DMG or from the Downloads folder. Since macOS 10.12, Gatekeeper runs apps from a randomized read-only path (/private/var/folders/...) called an App Translocation point. It's a safety measure so a quarantined app can't reference files next to it. But it breaks apps that expect to find resources relative to their own path — plugins, license files, sibling binaries. The app reports itself as damaged because pieces it depends on are suddenly missing.

Check whether translocation is active:

xattr -p com.apple.quarantine /Applications/YourApp.app

If the path in the running process looks like /private/var/folders/..., that confirms it. The real fix is simple: move the app to /Applications before launching it. Drag it in Finder, then open it from there. Translocation only kicks in when an app is quarantined and not in a trusted location. Once it lives in /Applications with a clean quarantine flag, macOS stops scrambling its path.

If you can't move it (some apps insist on running from external drives), strip quarantine with xattr -cr as in Cause 1. That disables translocation for that bundle.

What not to do

You'll find advice telling you to run sudo spctl --master-disable and turn Gatekeeper off entirely. Don't. That disables the check for every app, forever, until you remember to turn it back on. You're trading a five-second fix for a permanent hole. The per-app approach above is safer and takes the same effort.

Also skip the sketchy third-party "Gatekeeper fixer" utilities floating around. They do exactly what xattr -cr does, and you have no idea what else they're touching.

Quick reference

Start with the xattr -cr command. If the app still won't launch, run codesign --verify --deep --strict and read the error — it tells you exactly which of the three causes you're looking at.