syspolicyd high CPU on Mac? Gatekeeper, explained

syspolicyd is the daemon behind Gatekeeper: it decides what's allowed to run on your Mac. High CPU means it's assessing an app's security, and it usually subsides once that app is checked and cached. When it doesn't, the cause is almost always another app making it re-check constantly.

What syspolicyd does

It enforces system policy: what may be installed, loaded, or executed. It maintains the policy database and is the process other parts of macOS ask for a Gatekeeper verdict. Since macOS Mojave it also handles notarization checks, and it authorizes kernel extension loading. The real one lives at /usr/libexec/syspolicyd, protected by System Integrity Protection.

Why it's using high CPU

Gatekeeper runs an assessment when you launch an app: scanning the bundle, validating its signature, checking notarization, and (with trustd) the signing certificate. Real spikes come from:

• First launch of a large, newly-downloaded (quarantined) app: the full scan runs once.
• An app that repeatedly spawns signed binaries. A documented case involved a developer tool whose file-watcher spawned thousands of git processes per second, each one forcing a fresh Gatekeeper check and pushing syspolicyd toward 180% CPU.
• Deprecated or blocked kernel extensions it keeps re-evaluating.

Is syspolicyd a virus?

No. The real /usr/libexec/syspolicyd is core macOS security and the Gatekeeper enforcer. Disabling it weakens your Mac's protection. As always, verify the process's path before trusting any "syspolicyd virus" claim.

Verifying takes one line. Note the PID beside the process in Activity Monitor, then in Terminal run ps -o comm= -p <PID>. /usr/libexec/syspolicyd is the genuine one, in a folder System Integrity Protection keeps read-only; anything running out of your home folder is not it. The same test answers the same question for every background process on your Mac.

What to do about it

1. Usually, wait it out. First-launch and scan spikes subside once the app is registered and results cache.
2. If it's sustained, find the app triggering it. Check Console for repeated security-assessment logs, then quit, update, or uninstall the app whose launches drive it. (In the developer-tool case above, the fix came from the app's vendor, not macOS.)
3. Reboot to clear a transient loop.
4. Don't try to permanently disable it: that's turning off Gatekeeper.

The three checks that run together

Part of what makes syspolicyd confusing is that it is one of three things happening at the same moment you double-click an app, and any of them can be the one using the CPU:

• syspolicyd holds the policy and gives the verdict: may this run at all?
• trustd evaluates the certificate chain the signature depends on, which can mean a network round trip to check the certificate hasn't been revoked. A launch that hangs rather than spikes is more often this one.
• XProtect matches the app against Apple's malware signatures.

Behind all three, Launch Services is what recorded that the app exists in the first place. If two or three of these names are busy together, you are watching one launch, not several problems.

How to see what it's actually checking

If the spike is sustained and you want the name of the app driving it rather than a guess, macOS logs every assessment. In Terminal:

log stream --predicate 'process == "syspolicyd"' --info

Leave it running for a few seconds. If one app's bundle identifier scrolls past over and over, that is your answer, and the fix is with that app — quit it, update it, or remove it — not with macOS.

The related thing worth knowing: a newly downloaded app carries a com.apple.quarantine tag, which is what triggers the full first-launch assessment. You will find advice to strip that tag by hand with xattr. Don't. It skips the check rather than passing it, on exactly the file type the check exists for, and it does nothing about a loop, which is caused by an app launching binaries rather than by the tag.

What people get wrong

The old assumption is that Gatekeeper only checks an app on its first run. That was true on older macOS. On Ventura and later, malware (XProtect) and code-integrity scans run on every launch; only the notarization result caches (about 12 hours). Repeated checking is expected behavior, not a bug.

See which app is making it work

syspolicyd spiking is a clue that some app is launching binaries over and over. Plumby shows live CPU with each process named plainly and the fix beside it, so you can trace the security-check load back to the app causing it instead of guessing, measured from your Mac's real state.