How to Run XProtect on Mac: 5 Subcommands, None of Them Scan

If you search for how to run XProtect on a Mac, you are probably after a malware scan you can start yourself. macOS 26 ships a command-line tool for XProtect, /usr/bin/xprotect. It has five subcommands, and none of them scans anything. I ran all five on my Mac mini without sudo. Three answered. The other two, check and update, printed "Command needs to be ran as root" and exited with code 255. Then I called the scanning modules directly. The first one exited in 18 milliseconds with code 27, printed nothing, and logged that its connection to the scan service had been interrupted.

The scanning happens anyway, on Apple's schedule rather than yours. On this machine the Remediator batch started between 23:48 and 23:51 on each of the last 7 nights. This post covers what the tool does, which parts need root, and how to check from the log that a scan ran.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), booted 2026-09-28, measured on 2026-10-19 as an admin user without sudo (sudo -n true answers "a password is required").

The xprotect command, subcommand by subcommand

$ xprotect
OVERVIEW: A utility for working with XProtect.

SUBCOMMANDS:
  update                  perform an XProtect update
  logs                    display XProtect logs
  version                 print the XProtect update version
  check                   print the currently available iCloud XProtect update
  status                  print the status of the XProtect subsystem

Subcommand	Without sudo	Exit	What it printed here
version	works	0	Version: 5367 Installed: 2026-10-14 14:48:13 +0000
status	works	0	launch scans: enabled, background scans: enabled
logs	works	0	2,467 log lines in 6.4 s, from 3 XProtect processes
check	refused	255	Command needs to be ran as root
update	refused	255	Command needs to be ran as root

version, status and check take --json, which is the form to use in a script or a monitoring check:

$ xprotect version --json
{"xprotect_bundle_version":"5367","xprotect_bundle_install_date":"2026-10-14T14:48:13Z"}

$ xprotect status --json
{"xprotect_background_scans":true,"xprotect_launch_scans":true}

update has one option, --prerelease, which its help text describes as using "the available prerelease update ahead of general availability". logs takes no options. The binary's strings include show and --predicate, so it looks like a wrapper around the log show command with a fixed filter. The 2,467 lines it printed came from XProtectPluginService (2,164), XprotectService (243) and XProtectUpdateService (59). They did not include a single scan result. Those are in a different subsystem, which I cover below.

What "run XProtect" means in practice

XProtect is several things that share a name. Apple's Platform Security guide describes the signature check, which runs when an app launches for the first time, when an app changes on disk, and when the signatures update. You start that one by opening the app; there is nothing to call. The second part is XProtect Remediator, a set of per-family scanners that run in the background. On this Mac there are 25 of them in /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/, from XProtectRemediatorAdload to XProtectRemediatorWaterNet, and each one is a universal binary signed as com.apple.XProtectFramework.plugins.<Name>.

Calling one directly is the obvious next step, and it does nothing useful without root:

$ /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorEicar
$ echo $?
27

$ /usr/bin/log show --last 5m --style compact --predicate 'process == "XProtectRemediatorEicar"'
... activating connection: mach=true ... name=com.apple.XprotectFramework.PluginService
... F  XProtectRemediatorEicar[79105:2c82abc] [com.apple.XProtectFramework.PluginAPI:XPAPIHelpers]
       XPC connection to com.apple.XprotectFramework.PluginService interrupted.

XProtectRemediatorTrovi gave the same exit code 27. The modules don't scan on their own. They ask the plugin service to do the work, and the service turns down a caller it doesn't trust. I did not retry with sudo. This is a 24-hour remote machine, and Remediator modules are built to delete what they find.

When the scans actually run

The schedule is in launchd plists, linked from /Library/Apple/System/Library/LaunchDaemons/ and LaunchAgents/ into XProtect.app. The daemon copy (com.apple.XProtect.daemon.scan) runs as root and the agent copy (com.apple.XProtect.agent.scan) runs as the logged-in user. That is the split covered in LaunchAgent vs LaunchDaemon. Both declare the same three XPC activities:

$ plutil -p .../com.apple.XProtect.daemon.scan.plist
  "com.apple.XProtect.PluginService.daemon.fast.scan" => { "AllowBattery" => true,  "Interval" => 21600 }
  "com.apple.XProtect.PluginService.daemon.scan"      => { "AllowBattery" => false, "Interval" => 86400 }
  "com.apple.XProtect.PluginService.daemon.slow.scan" => { "AllowBattery" => false, "Interval" => 604800 }

That gives intervals of 6 hours, 24 hours and 7 days. A separate job, com.apple.XProtect.daemon.scan.startup, has RunAtLoad set and runs once at boot. Interval is a target, not a clock time, because the activity scheduler picks the moment. Here is what the scheduler actually picked, read from 15 days of unified log (80,669 lines from the XProtect and Remediator processes, 2026-10-04 to 2026-10-19):

The XProtect process woke at about 02:36, 08:36, 14:36 and 20:36 every day from 10/11 onward, which matches the 21,600-second fast-scan interval: every wake fell between :35 and :37 past the hour. Remediator processes started at 23:48:28, 23:48:56, 23:48:27, 23:50:54, 23:49:24 and 23:49:09 on 10/12 through 10/17, and at 23:48 on 10/18. Howard Oakley's write-up of the scan scheduling describes the daily scan as the main one, with each module run once as the agent and once as the daemon. That is what the 10/18 batch shows.

How to see the scan results

The results are not in xprotect logs. Each module writes one JSON line to its own subsystem and category:

$ /usr/bin/log show --last 15d --style compact \
    --predicate 'subsystem == "com.apple.XProtectFramework.PluginAPI" && category == "XPEvent.structured"'
2026-10-18 23:48:59.578 Df XProtectRemediatorFloppyFlipper[99495:2a83f98] [...:XPEvent.structured]
  {"status_message":"NoThreatDetected","status_code":20,"execution_duration":0.000123,"caused_by":[]}

Use /usr/bin/log rather than bare log if you are in zsh, because the shell has a builtin with the same name. The query returned 52 reports. 48 said NoThreatDetected (status 20), and 4 said Success (status 0). The four were MRTv3 twice and Conductor twice, each with an empty caused_by. 24 of the 25 modules reported, most of them twice, which fits one agent run and one daemon run. Trovi reported 6 times. Eicar, named after the standard antivirus test file, didn't report at all.

There is a gap I couldn't close. All 52 reports are from the 10/18 batch. On the six nights before that, the log has lines from four to five Remediator processes (DubRobber, MRTv3, Pirrit, SnowBeagle, SheepSwap) but no XPEvent lines. From here I can't tell whether the other modules skipped those nights or their lines have aged out of the log store. So if your own query comes back empty, it doesn't prove that no scan ran. Try the last 48 hours before you conclude anything.

Updating XProtect: two paths, three hours apart

The definitions arrive by two routes, which Oakley lays out in How XProtect is updated. softwareupdated installs into /Library/Apple/System/Library/CoreServices/XProtect.bundle, and XProtectUpdateService pulls from iCloud into /var/protected/xprotect/XProtect.bundle, which is the copy that's actually used. My /var/log/install.log shows the first route. It has 19 XProtect installs since 2026-05-15: 17 of XProtectPlistConfigData (5344 to 5367, with 5348–5350, 5359, 5361, 5364 and 5365 never installed) and 2 of XProtectPayloads, the Remediator modules (157, then 163 on 09-19). Every one since 2026-09-02 (7 of 7) landed at about 20:36 local time, within a minute of the 20:36 XProtect wake. Earlier ones clustered at 18:49 and 21:17 instead.

Version 5367 shows the gap between the routes. install.log says Installed "XProtectPlistConfigData" (5367) at 2026-10-14 20:36:53 KST. xprotect version reports 14:48:13 UTC, which is 23:48:13 KST, and /var/protected/xprotect has the same modification time. The copy that XProtect uses arrived 3 hours 11 minutes after the legacy copy. That isn't a fault. It's simply why xprotect version can trail install.log on the same day. This rig has automatic macOS installs turned off, as covered in disable automatic updates on Mac, and the XProtect data kept arriving anyway because system data files are a separate setting.

If you want to force it, the order is: run Software Update, then sudo xprotect check, then sudo xprotect update if iCloud reports a newer version. I didn't run the sudo steps here.

What people actually ask

The Stack Exchange API finds 8 Ask Different questions with "xprotect" in the title, and none with "XProtect Remediator". The biggest by views are about forcing an update (Force Macs to run Xprotect updater through terminal, 4,614 views, from 2014, long before this tool existed) and about the log (Where does Gatekeeper/XProtect log to?, 4,157 views). One from 2022, How to Install XProtect Update When MacOS Fails to Install?, still has no accepted answer. On macOS 15 and later the answers are the sudo xprotect update and log show commands above. Questions about XProtect's CPU use come up too. I covered its neighbour in syspolicyd high CPU, and the 52 execution_duration values in the 10/18 batch add up to 5 milliseconds. That figure is what the modules report about themselves, not the wall time of the batch, which ran from 23:48 to 23:52.

FAQ

How do I run an XProtect scan manually on Mac?

There is no scan command. The xprotect tool in macOS 15 and later only has update, logs, version, check and status. The XProtect Remediator modules run on their own through launchd, nightly on a test Mac mini at 23:48 to 23:51, and running a module binary directly without root exits with code 27 and does nothing. The signature check runs whenever an app is first opened or changes.

How do I check if XProtect is up to date?

Run xprotect version in Terminal; it needs no sudo and prints the version and install date of the bundle in /var/protected/xprotect, which is the copy XProtect uses. To compare it with what Apple is offering, run sudo xprotect check, and if a newer version is listed, sudo xprotect update.

Where are XProtect scan results logged?

In the unified log, not in xprotect logs. Run /usr/bin/log show --last 2d --predicate 'subsystem == "com.apple.XProtectFramework.PluginAPI" && category == "XPEvent.structured"'. Each Remediator module writes one JSON line with a status_message such as NoThreatDetected.

Measured on 2026-10-19 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, booted 2026-09-28) as an admin user without sudo. The subcommand table is from running each subcommand once. Scan timing is from one /usr/bin/log show --last 15d capture filtered to the XProtect and Remediator processes (80,669 lines, earliest XProtect entry 2026-10-10), and scan results are from a separate capture filtered to XPEvent.structured (52 reports). Update history is from /var/log/install.log, which goes back to 2026-04-16. I ran two Remediator modules (Eicar, Trovi) directly, without root; I did not run check, update or any module with sudo. The community count comes from the Stack Exchange API on 2026-10-19. Schedule and update-path background is from Apple's Platform Security guide and two Eclectic Light articles.