syspolicyd High CPU: 1,400 Log Lines a Minute, 0.3% CPU

My rig writes about 1,400 syspolicyd log lines a minute, all day, and 405 of every 13,810 say Terminating process due to Malware rejection. That line reads like a detection. It is not one. I spent this slot taking the stream apart on a headless Mac mini, and the short version is: the number after Malware rejection is a process ID, nothing was terminated, and the daemon producing all that noise used 0.313% of one CPU while doing it.

That last number matters, because people do not find this daemon by reading logs. They find it because a fan spun up. When I checked Google autocomplete for syspolicyd on 2026-09-25, three of the top six completions were syspolicyd cpu, syspolicyd mac cpu and syspolicyd cpu usage. Seeding syspolicyd malware rejection instead returned zero completions. So the log line and the CPU question are two different problems that get confused with each other, and this post separates them.

The census

Rig: Mac16,10, M4, macOS 26.4.1 (25E253), arm64, headless, up 24 days. Everything below is /usr/bin/log show against one subsystem — the absolute path matters, because zsh has a built-in that shadows the log command.

/usr/bin/log show --predicate 'subsystem == "com.apple.syspolicy.exec"' \
  --last 10m --style compact | wc -l
#    13810

Per full minute across that window: 1413, 1386, 1331, 1431, 1413, 1359, 1413, 1332. Normalising the messages and counting them gives a stream with only six real shapes.

Message	Count / 10 min	Share
Unable to initialize qtn_proc: 3	8,112	58.7%
dispatch_mig_server returned 268435459	4,055	29.4%
failed to call driver: 0x3	405	2.9%
Unable (errno: 2) to read file at <private> for pid: N	405	2.9%
Terminating process due to Malware rejection: N	405	2.9%
Failed to terminate process: -1	405	2.9%

Two things fall out of the arithmetic. The qtn_proc line is almost exactly twice the dispatch_mig_server line. And the bottom four are all exactly 405 — not approximately. That is not four independent problems happening at similar rates. It is one event emitting a fixed four-line sequence, 405 times.

The number is a PID

Here is one sequence, unedited, all four lines inside the same millisecond on the same thread:

19:21:36.171 E syspolicyd[1239:325e772] Unable (errno: 2) to read file at
             <private> for pid: 61262 process path: <private> library path: (null)
19:21:36.171 E syspolicyd[1239:325e772] Terminating process due to
             Malware rejection: 61262, <private>
19:21:36.171 E syspolicyd[1239:325e772] Failed to terminate process: -1
19:21:36.171 E syspolicyd[1239:325e772] failed to call driver: 0x3

61262 appears on the line above as for pid: 61262. It is the process ID, repeated. It is not a signature ID, a malware family number, or an XProtect rule index. I checked all 405 and the pairing holds every time.

Every code says the same thing

I decoded each value against first-party headers on the machine rather than guessing:

• errno: 2 is ENOENT, no such file or directory. syspolicyd could not open the binary it was asked to judge.
• qtn_proc: 3 is ESRCH, no such process.
• 268435459 is 0x10000003, which is MACH_SEND_INVALID_DEST — defined at line 828 of MacOSX.sdk/usr/include/mach/message.h. The destination port is gone.
• Failed to terminate process: -1 came back as -1 in 405 cases out of 405.

ENOENT, ESRCH, invalid destination, failed kill. Four different subsystems all reporting that the thing they were handed no longer exists. The Malware rejection wording is what a fail-closed policy engine says when it cannot read a file: it refuses, and refusal gets logged in malware vocabulary.

The shape: nine PIDs, every thirty seconds

The 405 rejections are not scattered. Sorting the PIDs and splitting on gaps gives 57 runs, and the run-length histogram is {9: 39, 7: 6, 1: 12} — thirty-nine runs of exactly nine consecutive PIDs (61262–61270, 61302–61310, 61761–61769, and so on). Cluster start times alternate between gaps of 2.36 s and 27.64 s with almost no variance, so something fires twice on a 30-second cycle.

It is not a scheduled job. I enumerated StartInterval across every LaunchAgent and LaunchDaemon on the box and the shortest is 300 seconds. So it is a loop inside an already-running process.

You cannot catch these processes

I ran ps -Ao pid,ppid,command in a tight loop with no sleep for 70 seconds, collecting 5,454 distinct process lines. Of the 36 PIDs syspolicyd rejected during that window, I caught zero. Asking the log for anything the process itself emitted — --predicate 'processID == 61262' — also returns nothing. These processes do not live long enough for a busy-looping ps to see them once, which is exactly why syspolicyd loses the race too. Tracing the execs directly would need dtrace, and on a stock Mac System Integrity Protection blocks that.

The trap I nearly fell into

There is a second high-volume stream on this machine, and merging them would have produced a wrong post. The kernel logs ASP: Unable to apply provenance sandbox: 268451845 — that code is 0x10004005, MACH_RCV_INTERRUPTED — at 2,168 lines in four minutes, and unlike syspolicyd it does not redact the path: 1,719 of them name an Electron helper, 17 name Homebrew's node. It even has the same shape, 186 of its 213 runs being exactly nine consecutive PIDs.

Tempting conclusion: that app is causing the malware rejections. I checked instead of assuming. Parsing the PID field out of both streams and intersecting them gives 0 overlap — 144 rejected PIDs against 1,736 kernel PIDs, occupying the same range (69328–82478 versus 69743–82186) and never once coinciding. Same range, same shape, disjoint sets. Two noise sources, not one.

One methodology note, because it burned me mid-slot: do not grep a bare PID against the log. kernel[0:3269743] contains 69743 as a substring, so a raw grep for a PID matches thread IDs and hands you a confident, wrong answer. Parse the field.

So what does it actually cost?

This is the question people are really asking. Correct CPU measurement is a delta of CPU-seconds over wall-seconds — the %cpu column in ps is a lifetime average and useless for this.

# snapshot ps -Ao pid,time,comm before and after, diff the cpu-seconds
syspolicyd (pid 1239): 0.94 cpu-seconds over 300 s = 0.313% CPU

Over that same 300-second window syspolicyd ranked 19th on the box, below Finder at 0.68% and loginwindow at 0.56%. Its lifetime total is 23m 03s of CPU across 24 days of uptime — a 0.066% average — with a 35 MB resident set. It writes 1,400 log lines a minute and costs less than the Finder.

So if your Mac is hot and Activity Monitor is showing syspolicyd at 90%, this log stream is not your cause and quietening it will not help. That is a genuinely different failure — the daemon re-scanning real files in a loop, which is the pattern behind the other macOS daemon that gets blamed for heat. Measure the delta first. We keep having to relearn this: the actual cost of a background daemon is almost never what its log volume suggests.

This has been open since 2020

The same four-line sequence was reported to Apple in October 2020 by an engineer on Yandex's DevTools team, whose build farm was hitting it on Catalina 10.15.4. Their post quotes Unable (errno: 2) to read file ... for pid: 36603 followed by Terminating process due to Malware rejection: 36603 — character for character the pattern I measured today. An Apple DTS engineer replied asking them to follow up by email, and no public explanation was ever posted. The reporter eventually diagnosed it themselves as hardlink inode sharing and worked around it with clonefile(2).

That was six years and many macOS releases ago. On 26.4.1 the sequence still fires here roughly 40 times a minute. Worth noting one difference: in their case the termination sometimes succeeded and killed an unrelated sibling process. On my rig it failed all 405 times, which is the difference between a noisy log and a real bug.

The CPU side is no better documented. Apple's own forum thread on syspolicyd high CPU runs from the Catalina beta in 2019 through 2024 across 21 replies with no official answer; the community remedies are to quit Acrobat Reader or delete leftovers from /Library/Application Support. Searching Stack Exchange's API for questions titled syspolicyd returns four on Ask Different and zero on Super User, Stack Overflow and Server Fault — and all four ask about CPU, disk or battery. Not one asks what the log lines mean.

Measured on 2026-09-25 on one machine: a Mac mini (Mac16,10, M4) running macOS 26.4.1 build 25E253, headless, 24 days uptime, in a scratch directory under /tmp. Log figures come from a single 10-minute log show window and a separate 4-minute kernel window; the CPU figure is a 300-second ps delta. Error constants were resolved against the SDK headers and errno on this machine, not from memory. What I could not establish: the identity of the rejected binaries, because syspolicyd redacts the path as <private> and unredacting requires a configuration profile I did not install in this slot — so I can describe the race but cannot name what loses it. The causal link between the two log streams is also unresolved; I report only that their PID sets do not intersect. One rig, one day: treat the rates as an existence proof, not a population estimate.