syspolicyd at 180%: When Your Fans Roar but the App Looks Idle

Your fans are screaming, the Mac is hot, and the app you'd blame is sitting at 2% CPU. The heat is real — it's just billed to a system daemon you've probably never thought about. Here's the mechanism, and how to find it on your own machine.

By CoreGuard · Jun 27, 2026 · updated Jul 6, 2026 · 14 min read

What is syspolicyd?

syspolicyd is the macOS system-policy daemon behind Gatekeeper: it checks the code signature and notarization status of programs before they run, and it normally barely registers in Activity Monitor. One common cause of syspolicyd pegged at 100–180% CPU — and the one documented in this article — is something on your Mac launching executables in a tight loop, thousands of short-lived processes a second, where every launch can trigger a Gatekeeper check. In that case the daemon isn't broken; it's doing exactly its job, at a rate nobody intended. What follows is a documented real-world case of exactly that, and how to catch it on your own machine.

▶

▶ Prefer to listen? Audio overview A podcast-style take on the syspolicyd CPU storm — for the commute, not just the screen. Plays an audio file hosted on this site — no YouTube.

Picture the scene, because you've probably lived it. The fans on a MacBook spin up to jet-engine and stay there. The aluminium gets hot. Everything starts to stutter — the beachball, the lag, the sense that the machine is working very hard at something. So you do the reasonable thing: you open Activity Monitor, you look at the app you've had open all day, and… it's sitting at two percent. Idle. Innocent.

That moment — hot machine, calm app — is where most people give up and blame the hardware, or reach for a "cleaner." Both are wrong. The work is real and it's measurable. It's just not where you're looking.

Here's a recent, well-documented example that makes the mechanism beautifully clear, reported on GitHub as openai/codex#29084. It's about one app, but the failure mode is general, and once you see it you'll spot it everywhere.

What actually happened

On June 19, 2026, a developer (@0xtootoo29) opened an issue against the Codex desktop app for macOS. The symptom: fans maxed, system-wide beachballs, thermal throttling, battery draining — the full hot, loud, and stuttering experience. But the Codex process itself was using almost no CPU. Their words, paraphrased: it looks like a GPU or rendering problem, because the obvious suspect is idle.

They didn't stop at the symptom. They traced it. Codex desktop runs a source-control watcher — a background feature that keeps an eye on your repo so the UI can show git status. Reasonable on its own. But the reporter's workspace was a reported 41 GB repo with 18 embedded (nested) git repositories inside it. The watcher recursed into every nested repo and ran git against each, continuously. The measured result was a reported ~4000 git processes spawned per second.

Four thousand short-lived processes a second. That number is the whole story. Everything else is just explaining why four thousand git launches a second turns into a heat problem that hides from you.

The app at the center of it used almost no CPU. The CPU was all in syspolicyd at a reported ~180% and trustd at a reported ~100% — two daemons most people have never deliberately looked at.

The environment, for the record and so nobody over-generalizes: a reported Codex Desktop build 26.611.x / 26.616.x, macOS 26.5.1 (25F80), Apple Silicon (Darwin 25.5.0 arm64), git 2.50.1. A separate report, openai/codex#25719, describes the same syspolicyd/trustd runaway on an M5 MacBook Air — so it's not one freak machine. As of June 27, 2026, the issue is still open; there's no shipped maintainer fix yet, only the reporter's own workarounds. I'm attributing every number to that thread on purpose: these are measurements from specific machines and builds, not a universal claim about the tool.

And to be clear about the spirit here: this isn't "Codex bad." Codex isn't doing anything malicious, and a watcher that recurses too eagerly is an ordinary bug that any of these tools could ship. The interesting part — the part worth your ten minutes — is why thousands of harmless little git commands turn your Mac into sustained heat, fan noise, and throttling, and why the cost shows up somewhere you'd never think to look.

Why a flood of tiny commands becomes a CPU fire

Here's the piece that breaks intuition, and it generalizes far past this one app. On macOS, launching a program is not free. As a process starts, macOS may run a code-signature and policy check — Gatekeeper, the security machinery that makes sure software is signed and notarized before it runs. That work is handled by a system daemon called syspolicyd, with help from trustd, which evaluates the signing certificate. Apple did this for good reasons: it's a big part of why random unsigned malware doesn't silently execute on your Mac.

For one app launch, this is invisible. Microseconds. You'll never feel it. The whole design assumes programs start occasionally — you open an app, you run a command. It does not assume something will try to launch a signed binary four thousand times a second, forever.

So picture the multiplication. git is a real, signed executable. Run it once: Gatekeeper shrugs, microseconds. Run it 4000 times a second: now syspolicyd is doing 4000 policy evaluations a second and trustd is checking certificates just as fast, and that per-launch overhead — trivial in isolation — stacks into a wall of sustained CPU. The cores heat up. The fans respond. The chip throttles to protect itself. The battery drops. All of it traceable to a watcher quietly running git in a loop.

And this is the crux of why you can't see it: the CPU time is billed to the daemons, not to the app that triggered them. Codex asks the OS to run git; the OS runs git; Gatekeeper inspects git; the meter spins under syspolicyd. The app that started the avalanche shows up as nearly idle, because in a narrow accounting sense it is — it's just standing at the top of the hill giving the snowball a push every quarter-millisecond.

Why your eyes go to the wrong place

So you open Activity Monitor and you make the same mistake almost everyone makes. You sort by app. You look for the program you recognize. And the two processes actually burning the CPU — syspolicyd and trustd — slide right past your eyes, because they look like background system noise. They have no icon. You didn't launch them. Their names mean nothing unless you happen to know macOS internals. So you dismiss them and keep hunting for a culprit with a face.

There are three smaller traps layered on top of that one.

The first is the >100% number. Activity Monitor counts a fully-used core as 100%, so a daemon hammering two cores reads as ~180%. People see "180%" and assume it's a glitch or a rounding error. It isn't — it's nearly two full cores of signature-checking, which is exactly as much heat as it sounds.

The second is the Energy tab. macOS does try to attribute energy back to the responsible app, but in a storm like this the attribution gets muddy: the daemons are doing the work, the kernel is scheduling it, and the picture you get is "system is busy," not "this watcher is the cause." Useful, but it won't hand you the answer.

The third is the deepest: Activity Monitor is a snapshot, not a recording. It shows you now. It can't show you that the fans started climbing the instant you opened that one big repo, or that syspolicyd has been pegged for forty minutes. Cause and effect live in the shape over time — the daemon line and the fan curve rising together while the app stays flat — and a single glance throws that shape away. Quit the app, the storm stops, the evidence evaporates, and the next time it happens you start the guessing game from scratch.

Put the four together and you get a genuinely hard puzzle: the hot processes are nameless to you, the percentages look impossible, the energy view is vague, and the one chart that would solve it instantly — who got hot, and when — is the one nothing on the machine is keeping.

How to check your own Mac in five minutes

If your fans are loud right now and the obvious app looks innocent, here's the fastest way to either confirm this pattern or rule it out. None of it changes anything on your system — it just looks.

1. Watch the spawn rate. In Terminal: for i in $(seq 1 10); do echo "git procs: $(pgrep -x git | wc -l)"; sleep 0.3; done. A calm machine prints 0–2. A storm prints dozens to hundreds, over and over. (Swap git for any helper you suspect.)
2. Find what's actually hot. Open Activity Monitor and sort by %CPU, or run top -o cpu in Terminal. In this pattern syspolicyd and trustd are at or near the top — not the app you opened.
3. Confirm the suspect is idle. Note the app's own %CPU (or run sample <pid> against it). If it's low while the daemons are pegged, you've found the mismatch that defines this bug.
4. Tie it to the heat. Watch your fan RPM and temperatures rise with the storm. The honest test: quit the offending app and watch the CPU fall back to near zero within a second or two. That's your proof.
5. Apply the reported workaround (attributed). Per openai/codex#29084, running git config diff.ignoreSubmodules all (and git config core.untrackedCache true) reportedly dropped the spawn rate to ~0/s and syspolicyd to ~5%; and if those nested repos shouldn't be tracked in the first place, a structural workaround is to untrack them (git rm --cached <dir>) and .gitignore them. Those are the reporter's fixes on their machine — sensible, but not official guidance, so understand what they do before you run them.

This isn't really about Codex

It's tempting to file this under "one buggy app" and move on. That's the wrong lesson, and it's the one that leaves you blind next time.

The real lesson is the shape of the failure. macOS makes launching a signed program cheap-but-not-free, and a tight loop turns "not free" into a furnace. Anything that shells out rapidly can do this. File watchers that rescan a tree on every change. Build tools that fork a compiler thousands of times. Pre-commit hooks gone feral. Shell prompts that run a clutch of commands on every keystroke. A script stuck in a retry loop. Each individual launch is harmless; the rate is the poison. And in every case the bill lands on a system daemon — syspolicyd, trustd, the kernel — so the tool that started it keeps its innocent face in Activity Monitor.

The machine is hot. The dashboard points at "system." The app you'd blame is idle. That's not one tool's bug — it's a blind spot in how we watch our own Macs.

We've quietly filled our machines with always-on local software — coding agents, IDE assistants, sync daemons, indexers, local model runners — and any of them can develop a loop with this exact signature. The data to catch it exists the whole time: a process count that spikes, a daemon that climbs, a fan curve that follows. The failure isn't that the signal is hidden. It's that nothing on the machine is keeping the signal long enough for you to read it.

What I'm building CoreGuard to see

This is the reason I started building CoreGuard, so let me be concrete — and honest, because after everything above, hand-waving would be hypocritical.

CoreGuard watches the things that actually move during a storm like this. Live temperatures and fan RPM, CPU and system load — and, the part I care about most, it keeps a history of those readings with threshold alerts, so "the fans started climbing forty minutes ago" is something you can see instead of something you'd have had to be staring at the moment it began. It also tells you, in plain English, what's eating your Mac right now: the actual top process burning CPU — even when that's a system daemon like syspolicyd, not the app you suspected. That's the whole trick of this bug, surfaced instead of buried. The live readings, the danger warnings, and the "what's eating your Mac" readout are free, because knowing your Mac is cooking should never cost money. Per-app energy analytics, a one-tap way to quit a runaway process, and the exportable history are the Pro power tools.

Now the honest limits, stated plainly. CoreGuard does not fix this. It won't patch Codex, it won't reach into Gatekeeper, and it can't make a process storm stop — nor would I trust anything that claimed it could "optimize" the problem away. It observes and explains. The actual fix is still yours: update or quit the offending tool, or apply the reporter's git workaround. What CoreGuard changes is the part that took a curious developer with a terminal to uncover — it turns "my Mac is mysteriously hot and the app looks fine" into "here's the process that's hot, and here's when it started." It also makes zero network connections — no account, no telemetry; verify it yourself with lsof -i -nP | grep CoreGuard and watch nothing happen — and it's Developer-ID signed and notarized by Apple — the same Gatekeeper machinery this whole story is about.

CoreGuard isn't out yet — the download and checkout go live shortly. Pro is a one-time $29 (Family $49), perpetual, not a subscription, with a 30-day money-back guarantee. Danger visibility is always free; Pro is the power to act and the portable proof, never the knowledge that something's wrong.

So here's the honest ask: get notified and grab it free at launch, or see what Pro adds. Either way, next time your fans roar and the app looks innocent — don't trust the calm app. Sort by CPU, find the daemon that's actually hot, and watch when it started.

Frequently asked questions