tccd Is Busy. Your Privacy Broker Has Receipts.

tccd brokers macOS privacy permissions and remembers what you allowed or denied. High CPU is a clue to trace, not a malware verdict.

By CoreGuard · Jul 24, 2026 · 15 min read

What is tccd on Mac?

tccd is Apple’s Transparency, Consent, and Control daemon, the macOS privacy-permissions broker. When an app requests access to a protected resource such as the camera, microphone, screen, files, Accessibility, or another app, the request passes through TCC; tccd presents or coordinates the consent prompt and records the decision.

It is the process behind much of what you see in System Settings ▸ Privacy & Security. Apple’s protected-resources documentation describes the public side of the mechanism: an app asks for a protected resource, macOS prompts on the app’s behalf, and the system remembers whether you allowed or denied the request.

That makes tccd a broker, not the app using your camera and not the owner of your files. If a video-conferencing app asks for microphone access, the app is the requester, tccd is the privacy gate, and macOS records the outcome. Blaming the broker for every noisy customer at the gate is satisfying for roughly five seconds.

Apple does not publish a public manual page for tccd or document the daemon itself as a user-facing command. Its role is nevertheless visible through the TCC framework path, the com.apple.tccd identifier, Apple’s privacy APIs, the supported tccutil tool, and the permission behavior you can reproduce.

What permissions does tccd manage?

TCC covers access where macOS wants the user or an administrator to make an explicit privacy decision. Apple’s current Privacy & Security settings guide lists categories including:

• Camera and Microphone
• Screen & System Audio Recording
• Files & Folders
• Full Disk Access
• Accessibility
• Automation
• Input Monitoring
• Contacts, Calendars, Reminders, and Photos
• Bluetooth, Speech Recognition, and other protected services

The approval flow is not identical for every category. A camera request can produce an immediate Allow or Don’t Allow dialog. Full Disk Access and Accessibility commonly require the user to enable an app in System Settings. Automation decisions are scoped to one app controlling another app. TCC is an umbrella, not one universal prompt painted several colors.

A requesting app supplies a purpose string for many protected resources. macOS puts that explanation in the prompt, but Apple cannot make a developer write a useful sentence. Read the app name, the requested capability, and the reason. “Needs microphone access for calls” after you clicked Join is coherent. The same request from an unfamiliar app while you are reading email is not.

A legitimate tccd process does not make the underlying request trustworthy. It proves that Apple’s broker is carrying the request, not that you should approve it.

Why are there two tccd processes?

There are normally two tccd instances: a system daemon and a per-user agent associated with the logged-in session. Both run the same executable, whose code-signing identifier is com.apple.tccd — but their launchd labels are not identical. On a live check for this article on an Apple-silicon Mac running macOS Tahoe 26.5.2, the system LaunchDaemon was com.apple.tccd.system and the per-user LaunchAgent was com.apple.tccd. Keep the three ideas separate: the signing identifier of the binary, the launchd label of each service, and the process you see in Activity Monitor.

The split is deliberate. Some privacy decisions belong to a user session; others involve system-wide policy or protected services. Apple uses similar daemon-and-agent arrangements elsewhere in macOS because a logged-in user and the operating system do not share one undifferentiated security context.

You can see the pair without changing anything:

pgrep -lf tccd
ps -axo user,pid,ppid,%cpu,etime,command | grep '[t]ccd'

One process running as a system user and another in your account is not evidence that one is an impostor. Do not “kill the extra one.” At best, launchd starts it again. At worst, you interrupt a real permission decision and discard the timing evidence you needed.

What is the TCC database?

TCC remembers decisions in SQLite databases conventionally named TCC.db. The relevant paths are:

~/Library/Application Support/com.apple.TCC/TCC.db
/Library/Application Support/com.apple.TCC/TCC.db

The first is per-user. The second stores system-level policy. Together they can represent prior allows, denials, service names, client identifiers, code-signing requirements, and policy supplied by device management.

Both stores are protected on modern macOS — by TCC and the sandbox, not simply by System Integrity Protection. tccd itself writes decisions into them, so they are not read-only; the point is that you should not open them by hand. A normal shell is typically blocked even from reading them, and administrator status is not a license to dismantle the privacy boundary. Apple’s System Integrity Protection documentation is the related, broader rule for the OS as a whole: even the root account is restricted from modifying many protected parts of macOS, while specially entitled Apple processes handle permitted changes. Disabling SIP to reach a TCC database is the wrong direction.

Old forum posts often suggest disabling SIP, granting Terminal broad access, opening TCC.db with sqlite3, changing rows, or deleting the database. That is not diagnosis. It removes evidence, can disturb unrelated permissions, and relies on an internal schema Apple is free to change.

The supported interface is tccutil, not a handwritten SQL statement. If the database is locked or damaged, the useful evidence is the repeatable behavior and relevant log messages. Take that evidence to Apple Support or the Mac’s administrator instead of improvising database surgery.

How to verify that tccd is Apple’s process

A process name is just a string. A copied binary can call itself tccd, so verify structure rather than trusting the label in Activity Monitor.

The expected executable path is:

/System/Library/PrivateFrameworks/TCC.framework/Support/tccd

Start by checking the running processes:

pgrep -x tccd
ps -ww -p "$(pgrep -x tccd | paste -sd, -)" \
  -o user=,pid=,ppid=,etime=,command=

Then inspect the installed system binary:

TCCD=/System/Library/PrivateFrameworks/TCC.framework/Support/tccd

codesign -dv --verbose=4 "$TCCD" 2>&1
codesign -vvvv \
  -R='identifier "com.apple.tccd" and anchor apple' \
  "$TCCD"

The important checks are:

• The executable is under Apple’s TCC private framework, not /Applications, /Users, /tmp, or a download folder.
• codesign reports Identifier=com.apple.tccd.
• The explicit requirement using identifier "com.apple.tccd" and anchor apple succeeds.
• The code is an Apple platform binary.
• No third-party TeamIdentifier is present.

That last point trips up otherwise careful guides. Apple’s launch-constraint documentation says Team IDs are present in code signed for development, TestFlight, the App Store, or Developer ID distribution. Apple platform code mastered into macOS is a different signing category, so “no Team ID” is expected here.

Apple’s Code Signing Guide documents both codesign inspection and the anchor apple requirement. The combination of system path, signing identifier, and Apple anchor is much stronger evidence than a familiar filename.

If a process named tccd is running from a user-writable location or fails the explicit Apple requirement, stop approving prompts and preserve the output. High CPU by itself is not that evidence.

Why is tccd using high CPU?

A brief spike while macOS presents or records a permission decision is normal. tccd has work to do: identify the requester, evaluate existing policy, coordinate the prompt, process the answer, and update protected state.

Sustained activity is different, but it still is not a verdict. I would test these hypotheses in order:

• A prompt-and-deny loop. A foreground app may ask for a permission, receive a denial, and immediately ask again. Test it by canceling once, noting the app and action, then quitting that app. If the prompt and CPU activity stop together and return when the same action is repeated, the caller is the useful lead.
• A recent install or update. A newly installed or updated app may enumerate protected capabilities, check existing authorization, or rebuild its onboarding state. Compare the start time with the app’s installation or update and watch whether activity settles after that app finishes launching.
• Screen Recording or Full Disk Access churn. Apps that capture screens, provide remote support, index broad file trees, or install helpers may repeatedly inspect permission state. Open the corresponding Privacy & Security categories and compare the listed apps with what you just launched or changed.
• A locked or damaged TCC store. If unrelated apps all fail to retain decisions and TCC logs repeatedly mention database, lock, or authorization-state errors, the store becomes a hypothesis. One restart and a controlled retest are reasonable; deleting the database is not.
• A management profile reasserting policy. On a managed Mac, an MDM payload can deny or constrain privacy permissions. Apple’s Privacy Preferences Policy Control documentation says that when multiple payloads exist, macOS uses the more restrictive settings. Check System Settings ▸ General ▸ Device Management and ask the administrator before fighting a policy the Mac is required to restore.

Notice what is missing: a magic CPU percentage. Activity Monitor gives you a sample of current processor use, not the identity of the app that initiated a privacy request. One spike without context proves little.

The better pattern is temporal: tccd becomes busy, a prompt repeats, and the same app or permission change precedes each event. Repetition plus a reproducible trigger is evidence. A red number in a sorted table is decoration until you connect it to an action.

Trace the requester without damaging the evidence

Open Activity Monitor, choose View ▸ All Processes, select the CPU tab, and search for tccd. Apple’s CPU guide documents the CPU view and recent CPU history. Watch whether tccd rises only during a prompt or continues after the prompt closes.

Then check the Energy tab for the foreground apps you suspect. Apple describes Energy Impact as a relative measure, not a watt reading. The useful question is whether one app is also active whenever tccd is busy, not whether two unrelated columns happen to contain large-looking values.

Next, open System Settings ▸ Privacy & Security and inspect the relevant category. The list tells you which apps have requested or hold access; on releases that show recent-use indicators, note them. It is not a complete live attribution trace, so compare it with the last app you installed, updated, opened, or changed.

For a live TCC attribution stream, Apple documents this read-only command for administrators diagnosing Privacy Preferences Policy Control:

log stream --debug \
  --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'

Start the stream, reproduce the prompt once, then stop it with Control-C. Look for the requester’s bundle identifier and the protected service. Logs may redact details, and they may contain usernames, app identifiers, file context, or management information. Read before sharing.

Capture the before state, the exact action, the prompt wording, and the after state. That small timeline is more useful than force-quitting tccd and reporting that CPU fell after the process stopped. Processes are famously economical when dead.

Reset one permission with tccutil

Apple documents tccutil as the supported command for removing remembered authorization to a protected resource. Its syntax is:

tccutil reset <service> [bundle-id]

A targeted Screen Recording reset looks like this:

tccutil reset ScreenCapture com.example.app

That command clears the remembered Screen Capture decision for the specified app in the current user’s context. It does not grant permission. The next qualifying request can make macOS ask again, and you still choose Allow or Don’t Allow.

Confirm the real bundle identifier rather than copying the display name:

mdls -name kMDItemCFBundleIdentifier -raw \
  "/Applications/Example.app"

Apple’s resetting protected-resource access guide documents both the service-first syntax and the optional bundle ID. It also documents broad service-wide and All resets, but those are poor opening moves on a working Mac. Reset the one service for the one app whose behavior you can reproduce.

After the reset, reopen that app and repeat the original action once. Capture whether the prompt reappears, whether your choice persists, and whether tccd settles afterward. If the command reports an invalid service or bundle identifier, stop and verify the spelling and identifier. Do not answer an error by reaching for sudo, disabling SIP, or editing TCC.db.

On a managed Mac, a profile may restore the organization’s required policy after your test. That is not tccutil failing; it may be the device doing exactly what its administrator configured.

What not to do when tccd looks stuck

Do not delete either TCC.db, hand-edit its rows, disable SIP, unload com.apple.tccd, or repeatedly kill both instances. Those actions disturb privacy state while making the original caller harder to identify.

Do not approve a confusing permission merely to silence the prompt. Denial may prevent an app feature from working, which is preferable to granting camera, screen, Accessibility, or broad file access without understanding why it was requested.

And do not download a replacement tccd. The genuine binary ships inside macOS. A website offering a daemon-shaped spare part has already failed the interview.

What CoreGuard can show—and what it cannot

This is where CoreGuard can add useful context without pretending to have secret access to TCC.

CoreGuard shows live CPU, temperature, and fan RPM, names the top resource-using app or process in plain English, and keeps history so a short event can be compared with what happened before and after it. Every danger warning remains free. If tccd becomes the top process during a repeating permission prompt, you can preserve the timing instead of relying on one Activity Monitor screenshot.

The limit matters more than the feature list: seeing tccd use CPU does not reveal which app originated the permission request. CoreGuard cannot honestly infer that caller from processor activity alone. Use the foreground-app correlation, Privacy & Security categories, TCC attribution log, and targeted reset described above.

CoreGuard is local-only and makes zero network connections. It does not change permissions, edit either TCC database, reset privacy settings, or invoke tccutil for you. It observes and explains. Its read-only disk-space inventory and SSD health and endurance reads follow the same rule: evidence in, no system mutation out.

CoreGuard is pre-launch. If a local history of CPU, temperature, fan activity, and named processes would help the next time a daemon becomes noisy, you can get notified. You do not need CoreGuard to solve today’s problem, though. Activity Monitor, Apple’s signing tools, one carefully chosen log stream, and a targeted tccutil reset are enough to turn “tccd is using CPU” into an actual investigation.

The useful question is not “How do I kill tccd?” It is “Which app keeps asking the privacy broker to decide?”

How to trace which app is driving tccd

1. Establish the CPU pattern: Open Activity Monitor, choose View ▸ All Processes, select CPU, search for tccd, and record whether activity is a brief spike or continues after the permission prompt closes.
2. Check the app-side energy clue: Open Activity Monitor’s Energy tab and note which foreground app is active whenever tccd rises; treat Energy Impact as a relative correlation signal, not proof of causation.
3. Record the trigger: Write down the exact app, click, prompt wording, requested permission, and time; cancel once and reproduce the same action only once.
4. Inspect Privacy & Security: Open System Settings ▸ Privacy & Security, select the relevant category, and compare the listed or recently active apps with the app you last installed, updated, opened, or changed.
5. Capture a short attribution log: Run log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"', reproduce the request once, stop with Control-C, and save only the relevant redacted lines.
6. Confirm the bundle identifier: Run mdls -name kMDItemCFBundleIdentifier -raw "/Applications/Example.app" and verify that the result belongs to the suspected app.
7. Reset one decision: Run tccutil reset <service> <bundle-id>—for example, tccutil reset ScreenCapture com.example.app—to clear only that app’s decision for that service; do not use All, delete TCC.db, or disable SIP.
8. Compare before and after: Reopen the app, repeat the same action, make a deliberate permission choice, and record whether the prompt returns, the decision persists, and tccd activity settles.

Terms used in this guide

• TCC: Transparency, Consent, and Control, Apple’s macOS privacy framework for brokering access to protected resources and remembering policy decisions.
• tccd: The Apple daemon and per-user agent that evaluate TCC requests, coordinate consent prompts, and record decisions.
• TCC.db: The protected per-user or system SQLite store containing remembered TCC authorization and policy state.
• tccutil: Apple’s supported command-line tool for clearing remembered TCC decisions so a protected-resource request can be tested again.
• platform binary: Apple-supplied executable code mastered into macOS; unlike Developer-ID-signed third-party code, it can legitimately have no Team ID.
• Full Disk Access: A Privacy & Security category that allows an approved app broad access to files from other apps, backups, and certain administrative locations.

Frequently asked questions