What Is cfprefsd on Mac? Why 15 Copies Run at Once

My Mac mini is running 15 copies of cfprefsd right now. One belongs to root, one to me, and the other 13 belong to accounts nobody logs into: _neuralengine, _applepay, _lp, _modelmanagerd and so on. If you opened Activity Monitor, saw the same name listed again and again, and searched for what it is, this is the measured answer from one machine: what cfprefsd on Mac does, why there are so many, what keeps waking them, and what happened when I killed mine.

The machine is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), up 19 days, measured on 2026-10-17 without sudo. On the demand side, Google autocomplete for cfprefsd returned 43 completions that day. The top ones were what is cfprefsd, what is cfprefsd on mac activity monitor, cfprefsd disk writes and killall cfprefsd, so those are the four questions this post answers.

What cfprefsd is

/usr/sbin/cfprefsd is the preferences server. Every app that reads or writes a setting through UserDefaults (NSUserDefaults) or CFPreferences talks to it over XPC instead of opening the plist file itself, and cfprefsd caches the values and writes the files. The man page is two sentences long and dated October 25, 2011:

$ man cfprefsd
     cfprefsd - defaults server
     cfprefsd provides preferences services for the CFPreferences and
     NSUserDefaults APIs.

     There are no configuration options to cfprefsd.  Users should not run
     cfprefsd manually.

Howard Oakley's guide to preferences on Eclectic Light dates the service to OS X 10.9 Mavericks and describes the effect people trip over: once cfprefsd has read a preference file, it keeps those settings "even over many days, until you log out, shut down, or restart." The binary on 26.4.1 is 135,920 bytes and still ships x86_64, x86_64h and arm64e slices.

It runs as two different launchd jobs from the same binary. The plists are short enough to read in full:

$ plutil -p /System/Library/LaunchDaemons/com.apple.cfprefsd.xpc.daemon.plist
  "EnablePressuredExit" => false
  "HardResourceLimits" => { "NumberOfFiles" => 512 }
  "MachServices" => { "com.apple.cfprefsd.daemon" => true }
  "ProgramArguments" => [ "/usr/sbin/cfprefsd", "daemon" ]

$ plutil -p /System/Library/LaunchAgents/com.apple.cfprefsd.xpc.agent.plist
  "EnablePressuredExit" => true
  "LimitLoadToSessionType" => "Background"
  "MachServices" => { "com.apple.cfprefsd.agent" => true }
  "ProgramArguments" => [ "/usr/sbin/cfprefsd", "agent" ]

The daemon (one copy, root) serves system-wide preferences such as /Library/Preferences and root's own. The agent serves one user's ~/Library/Preferences, and because it is a LaunchAgent, launchd starts a separate copy in each account's domain on demand. The agent is allowed to exit when the system wants memory back (EnablePressuredExit true); the daemon is not. If the agent/daemon split is new to you, I wrote up how launchd treats the two in LaunchAgent vs LaunchDaemon.

Why there are 15 copies of cfprefsd

This Mac has 133 accounts in its local directory (dscl . -list /Users), and only four of them lack the leading underscore: daemon, nobody, root and me. The rest are service accounts that Apple's daemons run as. Any of those daemons that touches its own preferences gets a cfprefsd agent in its account, and that agent can stay for weeks; launchd is allowed to retire it under memory pressure. Here is the full list from ps -axo pid,user,lstart,time,rss,args:

Account	Role	Started	CPU time
root	daemon	Sep 28 11:47	5:08.02
sg-mini (me)	agent	Oct 7 19:31	2:01.14
_cmiodalassistants	agent	Sep 28 11:53	0:07.36
_nsurlsessiond	agent	Sep 28 11:53	0:07.35
_installcoordinationd	agent	Sep 29 07:00	0:07.00
_modelmanagerd	agent	Sep 29 19:04	0:06.77
_neuralengine	agent	Sep 29 19:01	0:06.70
_securityagent	agent	Sep 28 11:53	0:06.22
_locationd	agent	Sep 28 11:47	0:05.87
_applepay	agent	Sep 28 11:53	0:05.83
_softwareupdate	agent	Sep 28 11:48	0:05.80
_audiomxd	agent	Sep 28 11:53	0:05.58
_accessoryupdater	agent	Sep 28 11:53	0:05.56
_rmd	agent	Sep 29 07:02	0:05.51
_lp	agent	Oct 10 07:33	0:02.76

All 15 together used 507 seconds of CPU over 19 days, about 0.03% of one core, and 57 MB of resident memory. The root daemon accounts for 308 seconds of that, mine for 121, and each of the 13 service-account agents for under eight. Ten days ago, when I checked for a post on why killall Dock matches nothing, there were 14; the count drifts as agents are retired and restarted.

This also answers an Ask Different question from 2023 that asked why another user appeared to be logged in: cfprefsd, trustd and secd were running under a child's account that had not been used in months. The accepted answer is the same thing the table shows. The owning user does not need to be logged in; launchd starts these per-user processes when something needs that user's data.

What keeps waking the system-account copies

I expected the 13 service-account agents to be idle leftovers from boot. The unified log says otherwise. In one hour (12:33 to 13:33, read with log show and --predicate 'process == "cfprefsd"') the 15 processes logged 1,906 lines. Most were XPC connections opening and closing. 276 were refusals, and 269 of those came from two places:

• 132 rejected writes from contactsd, in six accounts: _neuralengine, _cmiodalassistants, _modelmanagerd, _lp, _nsurlsessiond and _installcoordinationd. The reason given is because Directory needed, and it is literal: /var/db/neuralengine is an empty folder with no Library inside, so there is nowhere to put com.apple.contactsd.plist.
• 137 rejected reads of com.apple.triald in my own domain, 127 of them from one process, duetexpertd, "because accessing these preferences requires user-preference-read or file-read-data sandbox access."

The contactsd part surprised me, so I sampled ps every half second for seven minutes. Contacts' daemon was being launched in 19 system accounts at once (root, _spotlight, _windowserver, _coreaudiod and 15 others), in a batch of 10 and then 9 sixteen seconds later. In the first complete batches each copy lived about a minute, and the next batch started 5 minutes 24 seconds after the first. One hour of contactsd log had 210 distinct PIDs (one long-lived copy in my account, 209 short ones) and 44,855 lines, mostly account-store and TCC connection errors. All 13 service accounts that have a cfprefsd agent are on that contactsd list; five other accounts on it had no agent at the time. That is the most likely ongoing reason the service-account copies exist on this machine, though I can only show the overlap, not the cause; I can't tell from here whether a Mac with a normal logged-in GUI session sees the same loop.

E cfprefsd[26478] [com.apple.defaults:cfprefsd] rejecting write of key(s) <private>
  in { com.apple.contactsd, _neuralengine, kCFPreferencesAnyHost,
  /var/db/neuralengine/Library/Preferences/com.apple.contactsd.plist, managed: 0 }
  from process 98184 (contactsd) because Directory needed

If you came here from Console.app after seeing lines like this, they are cfprefsd doing its job: refusing a write it cannot complete, or a read the sandbox doesn't allow. On this machine they cost nothing measurable.

cfprefsd disk writes and high CPU

The per-process I/O counters are readable for your own processes through proc_pid_rusage (macOS refused it for the other 14 without root). My agent had written 140.18 MB and read 57.5 MB in 9 days 18 hours, an average of about 14 MB a day. Over a 319-second window this afternoon it wrote 0.03 MB.

The bad cases are real but old. The highest-viewed cfprefsd question is a Super User thread from 2015 (33,997 views) about cfprefsd above 90% CPU after the El Capitan upgrade. The highest-voted answer ran sudo fs_usage pid <PID> against cfprefsd and found the Bluetooth preferences file being rewritten in a loop; turning Bluetooth off stopped it. That is still the right method: cfprefsd's load is always someone else's preference traffic, and fs_usage shows which file. I didn't run it here because it needs root, and nothing on this Mac was slow. For the same "busy on behalf of someone else" pattern in other daemons, see what is spindump on Mac and syspolicyd high CPU.

What killall cfprefsd actually does

I sent SIGTERM to my own agent (PID 11631) right after writing a test key with defaults write:

old=11631
t+0.1s new=[]
t+0.2s new=[]
t+0.3s new=[35847]
defaults read -> 1 in 0.022s
$ launchctl print user/501/com.apple.cfprefsd.xpc.agent
	state = running
	runs = 3
	pid = 35847
	last exit code = 0

A replacement was running within about 0.3 seconds, before I asked for anything, presumably because another process on the machine asked for its preferences. The key written just before the kill was still there. The exit was clean (code 0), and the counter went from 2 to 3, which also explains the Oct 7 start time in the table: my agent had already exited cleanly once, and launchd's record can't say whether that was a signal or memory pressure.

Three things to know before you type it. Without sudo, killall cfprefsd only reaches the copy in your own account; the other 14 belong to other users, which I covered in the killall Dock post. Oakley's guide puts killing cfprefsd among the methods it calls "prone to failure and causing weird behaviour," behind using the app itself or the defaults command. And the usual reason people kill it, to make a hand-edited plist take effect, didn't hold in my test for defaults write on Mac: defaults read saw direct file edits immediately, and the app that missed them was the one already running. Writing through defaults or plutil and then restarting the app is the safer order.

What people ask about cfprefsd

To see which of these questions people actually bring, I pulled every Ask Different and Super User question that mentions cfprefsd anywhere, using the Stack Exchange API on 2026-10-17. That gave 46 questions with 165,041 views between them. Only four have cfprefsd in the title. I sorted them by what the asker was trying to do:

What the asker wanted	Questions	Views	Unanswered
Fix slowness, high CPU or disk, a freeze	12	67,496	2
Make a changed setting apply, or script one	12	24,868	4
Understand Console log lines	7	37,379	1
Explain processes under other users	2	2,262	0
Unblock an installer that wanted it closed	1	11,116	0
cfprefsd mentioned in passing	12	21,920	4

Performance draws the most views. Settings that won't apply are the weakest-served group: four of those twelve have no answer, including one from 2022 titled "Force reset system preferences cache." None of the 46 titles asks whether cfprefsd is malware, which matches the autocomplete list: people want to know what it is, not whether to delete it.

FAQ

What is cfprefsd on Mac?

cfprefsd is macOS's preferences server. Apps read and write their settings through it instead of opening plist files directly, and it caches the values and writes the files in Library/Preferences. One copy runs as root for system-wide settings, plus one agent per account that has used preferences since boot. It is part of macOS and should not be removed.

Why are there so many cfprefsd processes in Activity Monitor?

Each account gets its own cfprefsd agent, and macOS has many hidden service accounts such as _locationd, _applepay and _neuralengine. On a Mac mini running macOS 26.4.1 there were 15 copies: one root daemon, one for the logged-in user and 13 for service accounts. Together they used about 0.03% of one CPU core over 19 days.

Is it safe to run killall cfprefsd?

Killing your own cfprefsd agent is recoverable: in a test on macOS 26.4.1, launchd started a new one within about 0.3 seconds and a value written just before the kill was kept. Without sudo it only affects your account. It is rarely needed; writing settings with the defaults command and then restarting the affected app is the more reliable way to apply a change.

Related: trustd is another daemon that shows up once per account. On this Mac its system copy is the third-busiest process, and the log showed that 98% of its work was requested by syspolicyd. See what is trustd on Mac.

Measured on 2026-10-17 on one headless Mac mini (Mac16,10, M4) running macOS 26.4.1 build 25E253, 19 days uptime, without sudo. Process data is from ps and launchctl print, disk counters from proc_pid_rusage (only my own process was readable), and the log counts are one hour of unified log for cfprefsd and contactsd plus a seven-minute ps sample taken every 0.5 seconds. The contactsd launch loop may be specific to a Mac with no one logged in at the console. The kill test hit only my own agent, once. Stack Exchange numbers are every Ask Different and Super User question whose text mentions cfprefsd, classified by hand into the six groups above; demand figures are Google autocomplete completions, not search volume. I did not run fs_usage or any root command.