How to reset an app's permissions on Mac without reinstalling it

Resetting an app's permission on a Mac means deleting the one row macOS stores for that decision — allowed or denied, for one app, for one capability — so the app has to ask again the next time it needs it. There are two ways to do that: toggle the setting in System Settings > Privacy & Security, or run tccutil reset in Terminal, and for two specific permissions the toggle is the less reliable of the two. Neither route requires reinstalling anything.

This guide covers the GUI path in full, including the two panes where flipping a switch off and back on isn't a real reset, a complete reference table for every service name tccutil actually accepts, and — the part most guides skip — what a reset genuinely does not fix. For the base tccutil command syntax itself, see our guide to what tccd is and how it enforces every permission decision; we won't re-derive it here.

The GUI route: what toggling a permission actually does

Open System Settings > Privacy & Security, pick the pane for the permission in question — Camera, Microphone, Screen & System Audio Recording, Contacts, Calendars, Reminders, Photos, Bluetooth — and every app that has ever requested that capability is listed there with a switch. Flip it off, then flip it back on, and for most of these panes that's the entire job: the app can use the capability again the moment you turn it back on, with no new prompt.

That's worth pausing on, because it's not obviously what "reset" should mean. Turning the switch back on doesn't delete the stored decision and start over — it flips the same row's yes/no value back to yes. If what you actually want is a genuine fresh prompt — an app that mishandled a request the first time, or one you want to re-evaluate from scratch — toggling won't do it. Select the app in the list and click the − button instead, and its row disappears entirely. The next time the app requests that capability, macOS shows a real prompt, the same one it would show on a first install.

Full Disk Access and Accessibility: the two panes where even that isn't enough

For most panes, remove-then-let-it-re-prompt is reliable. Full Disk Access and Accessibility are where it breaks down, and both have the same documented workaround: remove the app, then fully quit it — Cmd-Q, not just closing its window — before re-adding it or letting it prompt again.

Keyboard Maestro's own troubleshooting page for this exact failure is blunt about it: unchecking and rechecking the Accessibility box "provides the satisfaction of a checkmark disappearing and re-appearing, but it doesn't repair" a stuck grant, and the documented fix is to remove the app from the list, quit it completely, and relaunch it before re-adding it. Keyboard Maestro's Accessibility Permission Problem page is worth citing directly here because Keyboard Maestro depends on this exact permission more than almost any other Mac app on the market, and its developer has been documenting this failure mode for years.

MacPaw's own Full Disk Access guide describes the identical pattern for that pane: simply toggling access off and on isn't the recommended fix, and re-granting it properly means you "remove the app from the list of all apps in Full Disk Access settings using the minus (-) button and re-add it using the plus (+) button" — then, a step most people skip, "Quit & Reopen" the app afterward (MacPaw's Full Disk Access guide, checked 2026-08-15). A process that's already running keeps whatever access it had when it launched; changing the row underneath it, by either method, often has no visible effect until the app quits and starts fresh.

Once you've removed and re-added the app for either of these two, our deeper guides to what Full Disk Access actually does and what Accessibility permission actually does cover exactly what each grant is worth being careful about handing back out.

The complete tccutil service-name table

tccutil reset takes a service keyword as its first argument, and Apple has never published an official list mapping those keywords to the Settings pane each one controls. The tool's own man page shows exactly one example, AddressBook, and stops there. Get the keyword wrong — it's case-sensitive — and the command does nothing, silently.

We built the table below by extracting every string prefixed kTCCService directly out of the tccd binary shipped in macOS Tahoe 26.5.2 (build 25F84) — strings /System/Library/PrivateFrameworks/TCC.framework/Support/tccd | grep -o '^kTCCService[A-Za-z0-9_]*' | sort -u — and matching each identifier to the pane it visibly controls in System Settings. Anchoring the match to the start of the string matters: a bare grep kTCCService also catches the token sitting inside a longer log or format string, and over-counts. Anchored and de-duplicated, that command returns 112 identifiers on this build; a different macOS version will very likely return a different number, since the count moves release to release — don't treat 112 as fixed if you run this yourself. Most of the 112 aren't something you'll ever type into Terminal: 32 are SensorKit categories for Apple Watch health metrics, and five — Facebook, LinkedIn, Twitter, SinaWeibo, TencentWeibo — are leftovers from macOS's old built-in social-sharing panes, retired from the interface years ago but apparently never deleted from the daemon itself. The table below keeps only the identifiers that correspond to something you can actually see, and reset, yourself.

One notable absence: Location Services isn't on this list because it isn't part of TCC at all. It's handled by a separate subsystem, locationd, which keeps its own record in /var/db/locationd/clients.plist rather than either TCC database — a distinction The Eclectic Light Company's dedicated piece on the subject confirms directly (checked 2026-08-15). tccutil genuinely cannot reset a location grant; System Settings > Privacy & Security > Location Services is the only door.

One app vs. every app: how much a single reset actually clears

Add a bundle ID and a reset is scoped to that one app: tccutil reset Microphone com.company.app clears only that app's microphone decision. Drop the bundle ID and tccutil reset Microphone on its own wipes that service for every app on the Mac at once — blunt, and occasionally exactly what you want if several apps' access has gotten tangled after an update.

There's a faster option for clearing everything one specific app holds, instead of resetting service by service: Apple's own man page for tccutil shows tccutil reset All com.apple.Terminal as its second example, and All works as a service keyword in its own right. Swap in any bundle ID and it resets every permission that app currently holds in one command.

Whether a reset needs sudo depends on which database the decision lives in. Camera, Microphone, and most of the panes above are tracked per user, so resetting your own grants doesn't need admin rights. A handful of system-wide decisions live in the other TCC database instead, and those need sudo tccutil reset to touch — our guide to what tccd is and where both TCC databases live covers that split in more depth.

What a reset does not fix

A tccutil reset, or the GUI equivalent, only ever deletes one row in one database. Three genuinely common situations look exactly like "the reset didn't work" and have nothing to do with TCC at all.

The first is a stale entry for an app you already deleted. Its row in Full Disk Access or Accessibility doesn't disappear when the app does — TCC keys everything to a bundle identifier, not to whether a file still exists on disk — and resetting the service clears the row, but the generic-icon entry you're staring at is a symptom of an incomplete uninstall, not a broken permission. Our guide on completely uninstalling an app on Mac covers where the rest of it actually lives.

The second is a login item or background helper that keeps re-requesting on its own schedule, independent of whatever you just reset. A reset stops one specific decision from carrying forward; it does nothing to a launch agent or daemon that's still installed and still running, and that process will simply trigger a fresh prompt again the next time it checks in — which can look, from the outside, exactly like the reset never took. Our guide on why Mac apps quietly gain new permissions after an update covers how these helpers accumulate in the first place.

The third applies only to Mac-managed machines, and no consumer-facing guide covers it: an MDM configuration profile can pre-approve a permission for an app through Apple's Privacy Preferences Policy Control payload, and that approval lives in /Library/Application Support/com.apple.TCC/MDMOverrides.plist — a separate file from either TCC database (Apple's own deployment documentation covers the payload). Run tccutil reset against an app covered by one of these profiles, and the row you just cleared comes right back, silently, the next time the profile re-applies. That's not a bug, and no local command can override it — it's IT policy, not something a reset was ever meant to touch.

Knowing a permission changed, before you go resetting anything

Everything above is the real, complete manual path — Settings, tccutil, and now, for anyone on a managed Mac, an MDM profile check too. None of it shows you, on one screen, which apps currently hold which permissions before you go reset anything. SwoopByte Permissions, the app we're building, reads both TCC databases — read-only, no sudo, zero network calls — and lists every grant by app instead of by pane, so you know what you're resetting before you reset it. It's an auditor, not a gatekeeper: like every app on this list, it has no way to grant, block, or intercept a permission prompt, because no consumer API for that exists. The audit stays free; a one-time $19.99 Pro adds full change history and ongoing monitoring. It's still in development — join the waitlist to hear when it ships.

FAQ

Does turning a permission off and back on in System Settings count as a real reset?

No, for most panes it just flips the same stored decision back to allowed without deleting it, so no new prompt appears. A real reset means removing the app from the list with the − button, or running tccutil reset SERVICE bundle-id in Terminal.

What's the tccutil service name for Full Disk Access?

SystemPolicyAllFiles is the keyword — for example, tccutil reset SystemPolicyAllFiles com.company.app clears one app's Full Disk Access grant.

Can I reset one app's permission without resetting it for every app?

Yes. Adding a bundle ID scopes the reset to that single app, for example tccutil reset Camera com.company.app. Leaving the bundle ID off resets that service for every app on the Mac at once.

Why does an app still ask for a permission again after I reset it?

That's expected, and it's the reset working correctly — a fresh prompt is exactly what a real reset produces. If the app instead behaves as if nothing changed, the more likely cause is a login item, launch agent, or MDM profile still granting it access independent of the row you just cleared.

Can a company-managed Mac block a permission reset?

Yes. An MDM configuration profile using Apple's Privacy Preferences Policy Control payload can pre-approve a permission outside either TCC database, in a separate file called MDMOverrides.plist. Resetting the TCC row on a machine covered by one of these profiles doesn't remove the override, and access returns the next time the profile re-applies.

Related guides