EndpointSecurity / EDR CPU (macOS)

When to Use This Skill

Platform Guard

macOS-only. EndpointSecurity, eslogger (macOS 13+), powermetrics, and systemextensionsctl are Darwin-specific.

test "$(uname -s)" = "Darwin" || { echo "macos-plugin: not Darwin, refusing"; exit 1; }

Core Insight: the EDR is usually a symptom, not the disease

An EndpointSecurity (ES) client — Kandji's ESF extension, XProtect's behavioral service, a corporate EDR — subscribes to the kernel's exec/open/rename event stream. Its CPU is proportional to the system-wide rate of those events. When something spawns hundreds of short-lived processes per second, every behavioral/security monitor must inspect each one, so they light up together:

XprotectService      behavioral malware scan, per exec
syspolicyd           Gatekeeper code-signing assessment, per binary
io.kandji…ESF        corporate EDR, per exec/open
trustd / tccd        cert eval / privacy, per access
auditd               audit record, per event
kernel_task          servicing the syscall + interrupt load

That column lighting up at once is the signature: one exec storm, taxing the whole stack. Restarting the EDR clears its queue for a few seconds, then the storm refills it. The fix is upstream — find and stop whatever is spawning the processes.

A hot ES extension with near-zero wakeups confirms this: it is draining a real inbound event queue in user space, not timer-spinning. High CPU with a high wakeup count and a quiet eslogger points instead at an internally wedged extension — the one case where restarting it (below) actually helps.

Diagnose

Both probes need root. If sudo isn't cached, hand them to the user with the ! prefix.

1. Per-process energy + wakeups — who is taxed, and is it spawn churn?

sudo powermetrics --samplers tasks --show-process-energy -n 1 | head -45

Read three things:

• DEAD_TASKS high (CPU + deadlines + wakeups) = a storm of processes that spawned and exited within the sample — the exec churn made visible.
• The security-stack cluster (XprotectService, syspolicyd, the ESF extension, trustd, tccd, auditd) all elevated together = the one-storm-taxes-all signature.
• The Wakeups column. Energy Impact understates VMs and wakeup-heavy tasks; a process with a huge wakeup count (e.g. a container VM) keeps the CPU package out of deep idle — the real battery cost on an otherwise "low energy" line.

2. The EndpointSecurity firehose — name the generator.

eslogger subscribes to the same stream the EDR consumes, and reports the initiating process. Rank the offenders over a short sample:

sudo eslogger exec 2>/dev/null | head -400 | jq -r '.process.executable.path' | sort | uniq -c | sort -rn | head -15

Whatever path dominates is the storm's source. If the stream scrolls instantly to 400 lines, the event rate itself is the problem. If it only trickles while the ESF stays hot, the extension is wedged internally — restart it.

Common exec-storm generators

Recurring sources, with the upstream fix that removes the load (not the symptom):

No-reboot levers

macOS rewards not rebooting — both the EDR and the inventory are inspectable and (mostly) restartable live.

• Restart a wedged ES extension (only if eslogger trickled while it stayed hot): sudo killall -9 <ESF-process-name>. sysextd relaunches the [activated enabled] extension within seconds. No reboot, no logout.
• Inventory + stale-version backlog: systemextensionsctl list. Over long uptime, each EDR update leaves the prior version as [terminated waiting to uninstall on reboot]. Those are terminated — zero CPU — pure disk/registry cruft that only a reboot clears, and never the performance problem. Don't reboot for them.
• Managed Macs: Kandji/JAMF EDR extensions can't be removed on a managed device. If the extension stays hot after the generators are gone and a reboot, escalate to IT — a persistently-hot EDR is a known agent failure mode they fix centrally.

Agentic Optimizations

Quick Reference

Related Skills

• launchservices-health — when launchservicesd (not an ES extension) is the hot process
• macos-incident-postmortem — when the load caused an actual hang/panic; reconstruct from DiagnosticReports