The root helper
System-wide monitoring uses a small privileged helper. It is optional, tightly scoped, cryptographically pinned to the app, and refuses to touch protected processes.
What the helper enables
macOS deliberately hides most of your computer from ordinary apps. A normal, unprivileged app cannot read the resource usage of processes owned by the system (root): the WindowServer that draws your screen, kernel_task, background schedulers like dasd, and the whole tier of system daemons. On a real machine the team measured this exactly: without privilege, Anomalous could read 0 of 166 root-owned processes. So if one of those hidden system processes is the thing draining your battery or pinning a CPU core, an ordinary monitor is simply blind to it.
The root helper closes that blind spot. It is a small, separate program that Anomalous can install with your explicit permission. Once installed, it runs as a privileged background service and can sample every process on the machine, then hand those readings back to the app. This is what turns Anomalous from user-app monitoring into system-wide monitoring. The helper is optional: if you never install it, the app still watches your own apps and simply skips the system tier.
Under the hood
The privileged sampler (sampleAll) reads per-process CPU, memory footprint, disk bytes, energy, GPU time, wakeups, and network bytes in/out, and returns them as JSON over XPC (AnomalousHelper/main.swift:57-61,112-151). When the app builds a tick it keys samples by pid from its own unprivileged collector first, then adds root samples only for pids it has not already seen (App/Sources/AppState.swift:635-650). The 0-of-166 measurement is documented at HelperProtocol.swift:5-9.
Why it needs privilege
Reading root-owned daemons requires root. There is no lesser permission that lets an app inspect processes it does not own; macOS returns permission-denied to unprivileged reads of another user's processes, and every system daemon is owned by root. To see them at all, the code doing the reading must itself run as root. That is the entire reason the helper exists, and it is why the helper is a distinct program rather than a capability bolted into the main app.
The helper's job is deliberately tiny. Its whole contract is two verbs plus housekeeping: sample every process, and stop one specific process, with a version check and a self-restart. Nothing else. A small, auditable root surface is treated as a feature here, not a shortcut: anything running as root is a high-value target, so the design keeps that surface small enough to read in a sitting and guards every privileged action.
Under the hood
The XPC protocol is four calls: sampleAll, terminate, version, and restartForUpdate (HelperProtocol.swift:14-40). The privileged mutation the helper can perform is a single SIGTERM to one guard-approved process; it reads metrics and identity but never file contents, keystrokes, or message data. See privacy for the full data shape.
How it is locked down
Running as root only makes the helper safe if it refuses to take orders from anything but the genuine Anomalous app. It does exactly that. The helper accepts instructions only over a private local channel (XPC), and only from a caller whose code signature it cryptographically checks. That caller must be signed by Anomalous's Apple Developer Team ID and carry the real app's exact bundle identifier — the real Anomalous, not merely anything signed by the same team. Unsigned or foreign-signed local programs are rejected.
In shipping (Release) builds this check is always on. The only way to skip it is a developer-testing bypass that is compiled out of shipped binaries entirely, so no environment variable, config file, or LaunchDaemon edit can weaken the signing check in a shipped root binary.
Under the hood
XPC client pinning: the code-signing requirement pins Team ID 7JQGQ7CRH8 and bundle id bot.anomalous.sensor (HelperProtocol.swift:60-67, enforced in main.swift:31-54). No bypass in Release: the ANOMALOUS_HELPER_ALLOW_UNSIGNED path is DEBUG-only and compiled out; Release enforcement is unconditionally on (main.swift:40-49). The app side also pins the helper's own signature to the Team ID and the helper's bundle id (HelperProtocol.swift:69-73), and launchd owning the privileged Mach name is what blocks impostor daemons.
Protected-process safeguards
When Anomalous asks the helper to stop a system process, the helper never blindly trusts the request. It re-validates the target against a shared, unit-tested policy before it acts. Three things must hold. The target must not be the system itself (pid 0 or 1). It must still be the exact same process the app meant — a pid-reuse guard that compares the process's live start-time fingerprint, because macOS recycles process IDs and the pid could now belong to an innocent new process. And it must not appear on a hard denylist of critical processes the helper will never signal, no matter what any diagnosis card or server requests.
Only if every check passes does the helper send a polite SIGTERM. If anything fails, it refuses and reports why. This is what lets Anomalous stop a misbehaving system process directly without the risk of a root-level kill hitting the wrong target.
Under the hood
Authorization runs through TerminationGuard.decide, a pure, unit-tested policy checking pid≤1, existence, start-time match, and the protected-name set (TerminationGuard.swift:38-49). The denylist includes launchd, kernel_task, WindowServer, loginwindow, logind, securityd, syslogd, opendirectoryd, coreauthd, trustd, syspolicyd, endpointsecurityd and more (TerminationGuard.swift:26-30). Before signaling, the helper re-reads the live start time and name and calls decide (main.swift:158-181), returning a numeric verdict: 0 terminated, 1 identity-changed, 2 gone, 3 not permitted, 4 unsupported, 5 protected. The app only delegates a kill to the helper when its own attempt returns not-permitted on a root-owned target (AppState.swift:1566-1574).
Removing it
The helper is installed through Apple's modern, user-visible path (SMAppService), so it also removes cleanly. Installation shows a one-time approval in System Settings → General → Login Items & Extensions — not a password prompt. To remove system-wide monitoring, turn Anomalous off in that same list; macOS unloads the privileged daemon. Uninstalling the app removes it as well. Without the helper, monitoring quietly continues for your user-owned apps only.
You will not be asked to re-approve or type a password after routine app updates. The helper heals itself: on each launch the app checks the installed helper's version, and on a mismatch it asks the helper to exit so launchd relaunches the updated binary from disk — silently, with no user action. And because the whole feature degrades gracefully, a helper that is missing or stuck can never freeze monitoring.
Under the hood
Installed as an SMAppService.daemon against bot.anomalous.helper.plist with RunAtLoad false, so launchd starts it on-demand at first connection (HelperClient.swift:142-159, LaunchDaemons/bot.anomalous.helper.plist:24-32). Install requires the app to be Developer ID-signed and notarized. Self-heal: restartForUpdate acks then exits after 0.2s so launchd relaunches the updated binary (main.swift:71-82); the app runs this once per session via reconcileVersion (HelperClient.swift:203-218). Every helper call carries a 5-second timeout and resolves to nil/false on any XPC error, so a hung helper never blocks the tick and the app falls back to unprivileged user-only sampling (HelperClient.swift:59-71).
For exactly what the helper reads, where it stays, and why none of it leaves your machine, see privacy. The sensor is open source — you can read the helper yourself at github.com/msitarzewski/anomalous-mac, and the public data corpus lives at github.com/msitarzewski/anomalous-corpus (PRs welcome).