Fix 'Operation not permitted' on macOS (Terminal & Apps)

You're in Terminal, trying to delete a file in ~/Library or maybe a script is reading a file in ~/Desktop, and you get Operation not permitted. Or you launched an app and it can't write to its own preferences folder. This isn't a permissions problem in the usual sense — chmod 777 won't help. What's actually happening is macOS's privacy system, called TCC (Transparency, Consent, and Control), is blocking access to protected locations like Desktop, Documents, Downloads, and some system folders. It's been doing this since Catalina, and it trips up a lot of people who are used to older macOS versions where Terminal had free rein.

Why you're seeing this

TCC keeps a database of which apps have been granted access to protected resources — location, camera, microphone, and also folders like Desktop and Documents. When you first run an app that tries to touch those folders, macOS should pop up a dialog asking for permission. But if you're running from a script, or the app is sandboxed, or you dismissed that dialog once and said "No," the block sticks. For Terminal specifically, the fix is to grant it Full Disk Access — that bypasses the per-folder prompts. For other apps, you might need to reset the TCC entry entirely, especially if the app was accidentally denied.

The other sneaky cause: sandboxed apps (like anything downloaded from the Mac App Store) can hit Operation not permitted when they try to touch files outside their container. That's a code-level restriction, and no amount of TCC clicking will help. But if you're running a normal app or a shell command, it's almost always a TCC block.

The fix

Give Terminal (or your app) Full Disk Access

Open System Settings (or System Preferences on older macOS) → Privacy & Security.
Scroll to Full Disk Access in the left sidebar.
Click the + button. If the app you need isn't listed, hit Cmd+Shift+G to jump to /System/Applications/Utilities/Terminal.app or wherever your app lives.
Select the app and click Open. For Terminal, that's Terminal.app in /System/Applications/Utilities/.
Restart the app. For Terminal, quit (Cmd+Q) and reopen. The change won't take effect until the process restarts.

That clears the block for most command-line access to Desktop, Documents, etc. If you're using iTerm2 or another terminal, add that instead.

Reset a denied permission for a specific app

If the app is stuck denied — maybe you clicked "Don't Allow" once — you can reset its TCC entry. You'll need to disable System Integrity Protection (SIP) to edit the TCC database, but there's a safer way: delete the app's preference file or use tccutil.

tccutil reset All com.example.yourapp

Replace com.example.yourapp with the app's bundle identifier (find it in /Applications/YourApp.app/Contents/Info.plist under CFBundleIdentifier). This resets all TCC permissions for that app — it'll prompt again next time it tries to access a protected folder.

If tccutil doesn't work because the app isn't signed or is a CLI tool, you can put it on the Full Disk Access list as above. That's the blunt hammer, but it works.

Sandboxed apps

For apps from the App Store, the sandbox is hard-coded. You can't grant them access to arbitrary folders via TCC — they're limited to their container. If you're writing a script and hitting Operation not permitted inside a sandboxed environment, you're fighting the sandbox. Move the file out of the container or run the command outside the sandbox (e.g., from a normal Terminal session). There's no toggle for this, and trying to work around it is a rabbit hole.

If it still fails

Check three things:

Restart the app after granting access. TCC checks the permission at launch. If you granted Full Disk Access but didn't quit and reopen, it'll still fail.
Verify the path isn't actually a symlink. Sometimes the file you're touching is a symlink pointing to a protected location. ls -l will show you. If it's a symlink, the target's protection applies.
Look at the actual error context. If you're doing rm -rf on a folder, you might get Operation not permitted because of a file within it that's protected by SIP (like /System). That's a different beast — you'd need to disable SIP, which you probably don't want to do.

One more thing: on macOS Monterey and later, Extended Attributes can also trigger this. Check with ls -l@. If you see com.apple.provenance or similar, that's a quarantine flag. It can interfere with scripts that copy files around. Run xattr -d com.apple.quarantine /path/to/file to strip it if that's the culprit.

Bottom line: for 90% of cases, Full Disk Access is the fix. For the rest, it's either a sandbox or a SIP-protected path. Don't waste time tweaking POSIX permissions — that's not what's stopping you.