macOS 'You do not have permission to open the application' Fix

You updated an app, tried to launch it, and got hit with "You do not have permission to open the application". No warning, no explanation, just a dead end. This one shows up constantly after macOS updates (Sonoma 14.4 and Sequoia 15 pushed a bunch of people into it), and it's especially common with apps you downloaded outside the App Store, or ones that auto-updated in the background.

The culprit here is almost always one of three things: a quarantine attribute left over from the download, a broken code signature after the update, or a permissions issue on the app bundle itself. Work through these in order and stop when it opens.

Quick Fix (30 seconds): Remove the Quarantine Flag

If the app was downloaded from the internet, macOS slaps a com.apple.quarantine attribute on it. After an update, that flag sometimes survives when it shouldn't, and Gatekeeper blocks the launch. This is the fastest thing to try.

1. Open Terminal (Spotlight → type Terminal).
2. Type the following, but don't hit Enter yet — you're going to drag the app into the window:

xattr -dr com.apple.quarantine 

3. Drag the app from Applications into the Terminal window. It'll paste the full path.
4. Hit Enter. Then try opening the app again.

If it still won't launch, move on. That fix only handles quarantine, not signature problems.

While you're there — check permissions on the bundle

Sometimes the app bundle's permissions get mangled. This is quick to check:

ls -la /Applications/YourApp.app/Contents/MacOS/

You want to see -rwxr-xr-x on the actual binary. If you see something weird like --------- or the owner is wrong (not you or root), that's your problem. Fix it with:

sudo chown -R $(whoami):staff /Applications/YourApp.app
sudo chmod -R 755 /Applications/YourApp.app

Don't go running chmod 777 on anything. That's a bad habit and it doesn't fix the actual issue.

Moderate Fix (5 minutes): Reset Permissions and Gatekeeper

If the quarantine removal didn't do it, you're likely dealing with a TCC (Transparency, Consent, and Control) permissions problem, or Gatekeeper has cached a bad assessment of the app.

Step 1: Right-click Open, not double-click

Sounds dumb, but it works more often than people admit. Right-click (or Control-click) the app in Applications, choose Open, and when the warning pops up, click Open again. This forces macOS to re-evaluate the app and add an exception. If the dialog gives you an Open Anyway button in System Settings, click it.

Step 2: Force Gatekeeper to re-assess

Run this to see what Gatekeeper thinks of the app:

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

If it says rejected, the signature is either broken or it's unsigned. You can try re-adding it:

sudo spctl --add --label "Approved" /Applications/YourApp.app
sudo spctl --enable --label "Approved"

On Sequoia, spctl --add has been quietly deprecated in favor of the UI path (System Settings → Privacy & Security → scroll down → Open Anyway). If the CLI doesn't work, use the GUI.

Step 3: Reset the app's TCC entry

If the app got updated and its code signature changed, TCC may be holding onto a stale grant. Reset it for that specific app:

tccutil reset All com.developer.appbundleid

Replace the bundle ID with the real one. You can find it with:

mdls -name kMDItemCFBundleIdentifier /Applications/YourApp.app

This is safe — it just forces macOS to re-prompt for permissions the next time the app needs them.

Advanced Fix (15+ minutes): Re-sign the App

If you've tried everything above and the app still refuses to launch, the code signature is genuinely broken. This happens a lot with apps that self-update (looking at you, certain Electron apps and older Adobe stuff). The fix is to re-sign it locally with an ad-hoc signature.

Warning: only do this for apps you trust. You're stripping Apple's verification.

Step 1: Strip the old signature

sudo codesign --remove-signature /Applications/YourApp.app

Step 2: Check what's inside

Apps with embedded frameworks or helper processes need those signed too. Check first:

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

Any code object is not signed at all lines point to frameworks that'll break the launch.

Step 3: Ad-hoc re-sign

sudo codesign --force --deep --sign - /Applications/YourApp.app

The - means ad-hoc — no certificate needed. It won't survive notarization checks, but it'll launch. You may need to redo this after every update. Annoying, but it's the price of running unsigned software.

Step 4: Clear Launch Services and reboot

macOS caches app metadata in Launch Services. If you've changed the signature, clear the cache so it re-reads everything:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user

Reboot after. This is the nuclear option — it'll reset your default apps for a few file types, but it clears a lot of stale state.

When It's Actually a Different Problem

A few cases that look like this error but aren't:

• MDM-managed Mac (work machine): Your IT department may have a policy blocking that app. No amount of chmod or codesign will help. Talk to them.
• SIP-protected location: If the app is in /System/Applications or similar, you can't modify it and shouldn't try. Reinstall from Apple.
• Rosetta 2 missing on Apple Silicon: Intel-only apps throw a different error, but it can be confused with this one. Install it with softwareupdate --install-rosetta.
• Broken symlink: If the app was moved or copied badly, the executable might point nowhere. Reinstall is faster than debugging.

My Take

Nine times out of ten, the quarantine removal or a fresh re-download fixes this. The re-signing route is a last resort — it works, but you're patching over a symptom. If an app keeps breaking its own signature after every update, that's a sign the developer isn't signing updates properly, and you should be using something else.

One last thing: after any of these fixes, if the app still won't open, check the system log. It'll tell you exactly why:

log show --predicate 'process == "YourApp"' --last 5m

Read the last few lines. The real error is usually in there, and it's more specific than what the dialog tells you.