What is tccd on Mac, and is it safe?

tccd is short for the TCC daemon — TCC stands for Transparency, Consent, and Control — and it's the background system process behind every "Allow" or "Don't Allow" prompt your Mac has ever shown you. It runs constantly, ships as part of macOS itself, and its job is to check whether an app is allowed to touch your camera, mic, screen, files, or a handful of other sensitive things, then write that decision down so it doesn't have to ask again. Seeing it in Activity Monitor, using a little CPU right after you install or open a new app, is normal. It is not malware, and quitting it doesn't turn off any protection.

What does tccd actually do on a Mac?

Every permission dialog you've ever clicked through — camera, microphone, screen recording, Full Disk Access, Accessibility, Automation, and more — is the same system underneath, and tccd is the process that runs it. When an app asks for access to something sensitive for the first time, tccd is what intercepts that request, shows you the prompt, and records your answer. After that, every future request from that same app goes through tccd again, silently: it checks its records, sees you already said yes (or no), and either lets the access through or blocks it without bothering you a second time.

It's a mediator, not a vault. tccd doesn't store your photos or your microphone recordings — it stores decisions: this bundle identifier, this capability, allowed or denied, as of this date. That distinction matters for understanding both why it can spike CPU briefly (below) and why deleting an app doesn't automatically clear those decisions — a point we cover in more detail in our guide to what happens to Mac app permissions after an update.

Where does tccd store its decisions, and can I open the database myself?

Every decision tccd makes lands in a SQLite database, and there are two of them: a per-user one at ~/Library/Application Support/com.apple.TCC/TCC.db, covering permissions tied to your account, and a system-wide one at /Library/Application Support/com.apple.TCC/TCC.db, covering permissions that apply system-wide regardless of which user is logged in.

You can't just open either file with a database browser, even as an admin. System Integrity Protection locks both folders down at the OS level — try ls on either path from an ordinary Terminal session and you'll get "Operation not permitted," no exceptions. The one legitimate way in is granting a specific app Full Disk Access, which is exactly the permission that lets Terminal, a backup tool, or a permissions auditor like the one we build read the databases' contents. Full Disk Access doesn't bypass SIP; it's the specific door Apple built for apps that genuinely need to see this much of the filesystem, tccd's own records included.

Why is tccd using so much CPU on my Mac right now?

A short spike is expected, and it's usually tied to something you just did: opening an app for the first time, letting several apps request permissions back to back after a fresh install, or macOS re-checking a batch of existing grants right after a system update. That's tccd doing its actual job — reading a request, verifying a code signature, writing or checking a database row — not a stuck loop or a memory leak. It should settle within a minute or two on its own.

Where a lot of quick-fix articles go wrong is jumping straight to "force-quit it" or "delete the app that's causing it" as the first move. Force-quitting tccd doesn't fix a permission problem — it's a system daemon managed by launchd, the same background-process manager behind every core macOS service, and launchd relaunches it automatically the moment it exits. You get no lasting benefit and a daemon that comes right back. Deleting apps one by one to find "the culprit" is a real last resort, not a first step; it's also unnecessary in the specific case where the spike is tccd validating something after a routine update, which resolves itself without touching any app at all.

If the high CPU use genuinely doesn't settle — it's still elevated ten or fifteen minutes later, with nothing new installed and no update running in the background — that's the point where it's worth opening Activity Monitor and checking what else is running, or checking Console.app for tccd logging the same request over and over for one specific app. A sustained, repeating loop tied to one app is a real signal to look at that app specifically; a brief spike after normal activity is not.

Is tccd safe, or could it be a virus?

tccd itself isn't something you install, and it isn't something that can quietly turn malicious on its own — it's an Apple-signed system process that ships with macOS, and there's no version of it that arrives bundled with a downloaded app or a browser extension. If Activity Monitor shows a process actually named tccd running from anywhere other than the system itself, that alone would be unusual — but the process showing up and using CPU, on its own, is not a sign of infection.

The real, documented risk isn't tccd going rogue — it's the opposite: sophisticated macOS malware attempting to get around TCC's checks entirely, so it never has to trigger a prompt you'd notice. Security researchers, including SentinelOne's SentinelLabs, have documented specific historical techniques for this over the years, most of which Apple has patched as they were found. That's a meaningfully different threat model than "tccd is dangerous" — the daemon is the thing enforcing the protection; the concern is software trying to slip past it, not the enforcer itself.

What's actually worth checking, as a normal user, isn't tccd — it's what it's recorded. An app holding Camera, Microphone, or Full Disk Access that you don't remember approving, or don't recognize at all, is the real, checkable signal. Our guide on seeing which apps can access your camera, mic, and screen walks through checking that by hand, one Privacy pane at a time.

What is kTCCService, and why do I see it in logs or Terminal output?

kTCCService is the prefix Apple uses internally for each permission category tccd tracks — it's the raw identifier stored in the database and printed in system logs, as opposed to the plain-language name shown in System Settings. A few you'll actually encounter: kTCCServiceCamera, kTCCServiceMicrophone, kTCCServiceScreenCapture, kTCCServiceAccessibility, kTCCServiceSystemPolicyAllFiles (that's Full Disk Access), and kTCCServiceAppleEvents (Automation).

You'll usually meet these codenames in two places: scrolling Console.app while diagnosing something, or reading tccutil's own syntax, which uses shorter friendly versions of the same names — Camera, Microphone, ScreenCapture, Accessibility, SystemPolicyAllFiles — rather than the full kTCCService form. Neither is something you need to memorize. They're worth recognizing so a raw log line reading kTCCServiceScreenCapture doesn't look like something more alarming than "this is about the Screen Recording permission."

How to reset a stuck tccd permission with tccutil

If an app's permission is stuck — showing as denied when you're sure you allowed it, or vice versa — the actual fix is resetting that specific decision, not restarting tccd. macOS ships a built-in tool for exactly this, tccutil, and the syntax is:

tccutil reset SERVICE [bundle-id]

A concrete example: to force an app to ask for microphone access again from scratch,

tccutil reset Microphone com.company.appname

Drop the bundle ID and tccutil reset Microphone on its own clears that decision for every app at once — blunt, but sometimes exactly what you want if several apps' mic access has gotten confused after a macOS update. To find an installed app's bundle ID: mdls -name kMDItemCFBundleIdentifier /Applications/AppName.app. tccutil can only reset a decision, never set one — Apple's own man page for the tool is explicit about that — so the app will show a real prompt the next time it needs that permission, exactly like a first install.

For anything that isn't fixed by a reset — an app you don't recognize holding Full Disk Access, or a permission you want to turn off outright — that's a System Settings job: Apple's guide to changing Privacy & Security settings on Mac covers the exact panes and toggles, and Apple's broader Platform Security guide documents how TCC fits into macOS's wider privacy model.

The faster way to see everything tccd has granted

Everything above is the real, correct manual path — tccutil, the Settings panes, and Console.app for the rare case where something is genuinely stuck. None of it gives you one screen showing every app and every permission it currently holds; that view doesn't exist anywhere in macOS itself. SwoopByte Permissions, the app we're building, reads the same two databases described above — read-only, no sudo, zero network calls — and shows every grant, organized by app instead of by pane, with a plain-language flag when an update quietly adds a new one. It's an auditor, never a gatekeeper: like every other app, ours included, it has no ability to grant, block, or intercept a TCC prompt on your behalf, because that consumer API doesn't exist. The audit is free and stays free; a one-time $19.99 Pro license adds change history and ongoing monitoring. It's in final testing now — join the waitlist to get it first.

FAQ

Is tccd a virus or malware?

No. It's an Apple-signed system daemon that ships with macOS and runs on every Mac, whether or not you've installed any third-party software. It's the process that enforces the camera, microphone, screen recording, and file-access permission system — not something that infects a Mac.

Can I force-quit tccd to fix high CPU usage?

You can, but it won't help. tccd is managed by launchd, which restarts core system daemons automatically the moment they exit, so it comes right back. If CPU use is genuinely stuck high for more than a few minutes with nothing new installed, check Console.app for one app repeatedly triggering the same request rather than quitting the daemon.

What is kTCCService in Terminal or Console logs?

It's Apple's internal naming prefix for a permission category — kTCCServiceCamera for Camera, kTCCServiceScreenCapture for Screen Recording, and so on. tccutil uses shorter friendly versions of the same names (Camera, ScreenCapture). Seeing the raw name in a log isn't a sign of anything wrong by itself.

Where is the TCC database located on a Mac?

There are two: a per-user database at ~/Library/Application Support/com.apple.TCC/TCC.db, and a system-wide one at /Library/Application Support/com.apple.TCC/TCC.db. Both are protected by System Integrity Protection — an app needs Full Disk Access to read them, and there's no supported way to open them directly with a generic database tool.

How do I reset a permission that's stuck?

Run tccutil reset SERVICE bundle-id in Terminal — for example, tccutil reset Camera com.company.app — and the app will prompt you again the next time it requests that permission. This only resets a decision; it can't grant one.

Does tccd slow down my Mac permanently?

No. Any CPU use from tccd is tied to an actual event — a permission request, a batch of apps checking in after an update — and it settles once that work is done. It isn't a background drain that runs continuously in the way a runaway third-party process can.

Related guides