laurigates/endpoint-security-cpu

EndpointSecurity / EDR CPU (macOS)

When to Use This Skill

| Use this skill when... | Use something else when... | |------------------------|----------------------------| | A security extension (Kandji ESF, XProtect, an EDR) sits at sustained high CPU | launchservicesd is the hot process — use launchservices-health | | Battery drains fast and powermetrics blames the security stack | The machine actually hung or panicked — use macos-incident-postmortem | | syspolicyd/trustd/tccd/auditd are all elevated together | One ordinary app is hot — use ps/top directly | | You suspect a process-spawn (exec) storm is taxing the system | Auditing kernel-extension inventory — systemextensionsctl list alone |

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):

| Generator (fingerprint in eslogger) | Fix | |---|---| | uvx --from git+https://… MCP / tools re-resolving the git source on every launch | Install once (uv tool install git+…) and invoke the bare command | | brew invoked in a loop (portable-ruby + Homebrew bash + git) — often a menubar "outdated" poller or per-invocation auto-update | export HOMEBREW_NO_AUTO_UPDATE=1; throttle/remove the caller | | Many concurrent dev/AI sessions spawning short-lived git/node/bun/gh | Collapse duplicate sessions; dedupe per-session helper servers | | A status tool shelling out on a tight timer | Lengthen its interval or cache its result |

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

| Context | Command | |---------|---------| | ESF extension CPU now | ps -Ao pcpu,comm \| grep -i ESF-Extension | | Storm source (top initiators) | sudo eslogger exec 2>/dev/null \| head -400 \| jq -r '.process.executable.path' \| sort \| uniq -c \| sort -rn \| head | | Security-stack energy snapshot | sudo powermetrics --samplers tasks --show-process-energy -n 1 \| head -45 | | Stale sysext versions (reboot-gated cruft) | systemextensionsctl list \| grep -c 'waiting to uninstall' | | Restart wedged ESF (sysextd relaunches) | sudo killall -9 <esf-process-name> |

Quick Reference

| Tool | Role | Root? | |------|------|-------| | powermetrics --samplers tasks | Per-process energy, wakeups, DEAD_TASKS churn | yes | | eslogger exec open rename | The ES event stream the EDR consumes; names the initiator | yes (macOS 13+) | | systemextensionsctl list | Extension inventory + reboot-gated stale versions | no | | ps -Ao pcpu,comm | Instantaneous CPU per process | no |

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