syspolicyd High CPU on Mac: Find the Trigger
If syspolicyd rises to the top of your CPU list after opening a downloaded app, start by checking what you just opened. Apple's Gatekeeper troubleshooting notes show syspolicyd handling system policy assessment, including notarization checks. High CPU alone does not identify the app involved or prove that anything is broken.
What syspolicyd is checking
Gatekeeper helps verify the developer of software distributed outside the App Store. Apple's code signing guide explains that an app and its signature are assessed on first launch, including nested code. syspolicyd participates in this security work, rather than running your app's features.
A new download's first launch is therefore a useful starting point. With an updated app, a large bundle, several downloaded installers or repeated developer builds, record which item was opened or replaced when the load began. These are investigation leads, not a guarantee that every download or build triggers the same assessment or takes longer.
For the broader process list and ownership checks, see Mac processes explained. This guide focuses on identifying a repeated assessment rather than cataloguing daemons.
Observe a quiet period before changing anything
Use the CPU list in Activity Monitor to watch syspolicyd and note when the load rises and falls. Apple's Activity Monitor guide documents process search, column sorting and the process information window.
- Record the app name, version and action immediately before the spike.
- Let an installation already in progress finish, without launching more new apps.
- Pause your own repeated build-and-launch cycle or queued app launches.
- Watch several successive CPU readings, then try one known app on its own.
A fall during the quiet period is useful evidence. It does not establish which earlier app caused the work. There is no fixed waiting time in this procedure, and one lower reading is weaker evidence than a sustained return toward the quiet baseline.
Separate a first assessment from a repeatable problem
Keep the comparison narrow so it changes only one input at a time.
| Observation | What it establishes | Next step |
|---|---|---|
| Load falls after new app launches stop | The activity subsided in that interval | Resume normal work and watch for a repeat |
| The same app repeatedly coincides with the spike | A reproducible correlation, not yet a cause | Record its version and inspect that specific copy |
| Load remains high without an identifiable trigger | The first-launch explanation is incomplete | Preserve observations and contact Apple Support |
If a build loop is involved, resume it once after the quiet comparison and note the result. If the spike returns, stop the experiment there. Avoid changing the build, installer source and security settings together, which would make the comparison unclear.
Investigate the particular app
Apple's troubleshooting notes distinguish damaged signatures from notarization problems. If the same copy repeatedly fails to open, get a fresh installer from its developer and keep your documents before replacing anything. An alert and a CPU spike are separate evidence.
For a developer or support investigation, Apple documents this signature verification. Replace the example path with the exact app being investigated, keeping the quotes:
codesign -v -vvv --strict --deep "/Applications/Example.app"
This verifies code without changing its signature. A failure needs interpretation by the developer, while a successful signature check does not prove notarization or explain CPU use. Send the result, app version, macOS version and reproduction timing to the developer. Do not repeatedly run verification while measuring whether the Mac has become quiet.
Keep Gatekeeper enabled
Disabling assessment changes a security boundary rather than repairing the app that triggered it. Apple's signing guidance explains why developer identity and notarization matter. Do not remove quarantine attributes or alter system policy databases as a CPU workaround.
If the Mac remains slow beyond this process, use why your Mac is slow to separate CPU pressure from other causes before removing apps or data.
Where Mole Fits
Mole Mac's Status page shows processes with CPU and memory usage, and its % CPU column can sort the list to bring busy processes into view. Mole does not change Gatekeeper policy. Use the list to observe the trend, not as an instruction to stop syspolicyd.
FAQ
Does high CPU mean syspolicyd is malware?
The name alone proves neither legitimacy nor malware. Check the process identity and the action that preceded the load before drawing a conclusion.
Should I disable Gatekeeper to stop the CPU use?
No. Keep the security checks and investigate the triggering app or repeatable workflow. If no trigger emerges, give Apple Support the observations rather than changing policy.
Why does it happen again with the same app?
A recurring spike is a reason to investigate that copy and its update or build workflow. It does not by itself prove a broken signature, a notarization failure or a macOS defect.