What all those processes on your Mac actually do

By CoreGuard · Aug 13, 2026 · 13 min read

What is a daemon on a Mac?

A daemon is a background program macOS runs to do a specific job — indexing files, syncing photos, checking code signatures — without a window or a Dock icon. Apple's launchd manual defines it precisely: a daemon is "a system-wide service of which there is one instance for all clients," while an agent is the same idea "on a per-user basis." Both are started and supervised by launchd, the first process the kernel launches, which relaunches them on demand or per each job's keep-alive configuration. In practice, when people say "daemon" about a Mac they mean both, and this guide does too.

Two properties follow from that definition, and they do most of the explaining on this page. First: you didn't start these processes, so a strange name in Activity Monitor is not evidence something is wrong — it's the default state of a working Mac. Second: because launchd supervises these jobs, force-quitting a system daemon is usually a no-op — it comes back, immediately or on the next demand, and whatever it was doing resumes.

Open Activity Monitor on any healthy Mac and you'll see hundreds of processes with names nobody chose for readability. The Mac this page was written on was running 757 of them mid-session — 146 owned by root, most of the rest by one logged-in user and a crowd of dedicated service accounts with names like _softwareupdate. (If those underscore accounts bother you, we built a lookup tool for exactly that.) None of this is bloat. It's how macOS is built: one small program per job, supervised, restarted when needed, mostly idle.

Killing daemons does not speed up a Mac

The oldest advice format on the internet — "disable these 10 processes to make your Mac faster" — fails on macOS twice. It fails mechanically, because launchd's job is to bring services back when they're configured to stay up or when something asks for them again; the man page calls it the "system wide and per-user daemon/agent manager." And it fails logically, because the daemon burning CPU right now is usually doing deferred work that will still be owed after you kill it: the Photos library still needs scanning, the Spotlight index still needs building, the sync still has to finish. Kill the worker and you don't cancel the work — you reschedule it, often for a moment you'd like less.

There are real cases where a daemon misbehaves — a corrupt cache it rebuilds forever, a stuck sync loop, a bug in a macOS point release. The honest response to those is specific, not general: identify the process, confirm the pattern is actually abnormal, then address the cause (often: an update Apple already shipped, or one broken input like a damaged library). The per-daemon posts linked below each carry their own decision tree, because "what to do" genuinely differs by daemon.

The one pattern worth learning: burst vs. plateau

Almost every "why is X using 100% CPU" panic resolves into one of these two shapes. After a macOS update, a big photo import, or a first login on a new Mac, the background machinery has real work to do, and it's supposed to use the machine to do it — that's the burst. It can last minutes or, for a full Spotlight or Photos pass, a day or two of intermittent effort. The plateau is different: the same process, the same load, long after any plausible job should have finished, often pinned at a suspiciously constant number. A burst you generally wait out. A plateau you investigate — with the four steps below and the per-daemon guides in the directory.

How to investigate any Mac process in four steps

1. Get the exact name. In Activity Monitor, sort the CPU tab by % CPU, and note the spelling precisely — coreduetd is not dasd, mds is not mds_stores. The name is the single most useful diagnostic fact, and it's free.
2. Establish what it's for. Look it up in the directory below (or its man page: man launchd, man trustd). Knowing the job turns "unknown process at 180%" into "the photo analyzer is analyzing photos".
3. Classify the shape, not the peak. Watch it over hours, not seconds: is it settling (burst) or flat (plateau)? Pair the CPU number with a symptom check — heat, fan behavior, battery drain overnight. A number with no symptom and a settling trend is usually a non-event.
4. If it's a plateau, go specific. Open the deep-dive post for that daemon below — each carries its own "is this the stuck case" checklist and the observable evidence to collect before changing anything. Resist the generic advice to force-quit: launchd brings it back — immediately or on the next demand — and you'll have destroyed the evidence.

The directory: 31 entries, by family

Definitions are deliberately short. Where a name links to a full post, that post is the deep dive — symptoms, the stuck case, and what you can investigate or change yourself versus what needs an Apple update. Descriptions of unlinked daemons come from their macOS man pages or, where Apple documents nothing, from what the binary's own framework home on disk says about its job — those are labeled.

Photos & media analysis

• photoanalysisd — analyzes your Photos library: faces and pets, scenes, objects, text. Powers People & Pets, Memories, and Photos search. Expect a long burst after big imports or a migration.
• mediaanalysisd — the system-wide sibling: analyzes images and video for features like Live Text and visual lookup, and can accumulate a large cache. Our post covers the runaway-cache case.
• photolibraryd — per its man page, "the photo library agent": it handles photo library requests — the library-management side of Photos, distinct from the analysis daemons above, and it can be busy with Photos closed.
• cloudphotod — the iCloud Photos transfer side. Its home on disk is Apple's CloudPhotoLibrary framework, which is also an honest one-line job description: moving your photo library to and from iCloud.

iCloud & file sync

• bird — the per-user iCloud Drive daemon behind "Documents in the Cloud": uploads, downloads, and local sync state for your documents.
• fileproviderd — the broker between Finder and File Provider–based cloud services (iCloud Drive, Dropbox, OneDrive, Google Drive among them): placeholders, downloads, local-versus-remote state.
• cloudd — per its man page, "the system daemon backing the CloudKit feature": app data that syncs through iCloud goes through here, not through bird.
• nsurlsessiond — per its man page, the per-user daemon that "performs tasks for background-configured NSURLSessions" — in plain English, the downloads and uploads other apps schedule to continue in the background. When it's busy, the real question is which app's transfers it's carrying.

Spotlight & indexing

• mds ("the metadata server", per its man page), mds_stores (the store-side writer that maintains the per-volume index stores), mdworker (the worker mds uses to scan and index files as a volume is mounted or a file changes, per its man page), and corespotlightd (the CoreSpotlight side — content apps donate for search; it lives beside mds in Spotlight's own Metadata.framework). Together they are Spotlight. Expect a heavy burst after a macOS upgrade, a new volume, or a migration; our post shows how to tell catch-up indexing from a stuck loop — including the disk-writes side most guides ignore.

Security & privacy

• tccd — Transparency, Consent, and Control: the privacy-permissions broker behind every "app would like to access…" prompt, and the keeper of those decisions.
• syspolicyd — Gatekeeper's assessor: first-launch checks, notarization verification, security policy. Our fans-loud post tells the story of its famous CPU storm and what actually triggers it.
• coreauthd — the LocalAuthentication broker behind Touch ID, Apple Watch, and password prompts.
• trustd — per its man page, "provides services for evaluating trust in certificates for all processes on the system": certificate-trust evaluations lean on it, so brief activity can be normal.
• XProtect — Apple's built-in malware scanning, documented in Apple's Platform Security guide as part of the Gatekeeper–notarization–XProtect stack; in a process list it shows up under names like xprotectd and XprotectService.

Intelligence & scheduling

• coreduetd — learns how and when you use your Mac to time the small conveniences (app suggestions, Handoff readiness). The post covers the whole Duet family and its can't-quit reputation.
• dasd — the Duet Activity Scheduler daemon (/usr/libexec/dasd): decides when deferred background activities actually run — backups, sync passes, analysis jobs — based on power, usage, and thermal conditions. Howard Oakley's 2026 write-up describes it loading roughly 700 background activities on a modern Mac. When "scheduled work never runs" or runs at odd moments, this is the scheduler behind it.
• peopled — coordinates people and contact context used across macOS. Paired in recent Tahoe threads with CallHistorySyncHelper; the post covers that duo.
• The Apple Intelligence family — intelligenceplatformd, knowledgeconstructiond, and their siblings build and serve the on-device knowledge graph. One post covers the family, because they misbehave (and settle) together.

Updates, audio, Find My

• mobileassetd — fetches and maintains the OS's separately-delivered data packages: dictation and keyboard assets, Siri voices, fonts, on-device Apple Intelligence models.
• softwareupdated — per its man page, "the main daemon responsible for running software updates". Busy around update checks and staged downloads; its underscore account _softwareupdate shows up in process lists too.
• coreaudiod — the Core Audio HAL: every sound in or out passes through it. The post covers why conference apps make it spike.
• searchpartyd — Find My's offline-finding daemon: the anonymous Bluetooth relay network that locates devices with no internet of their own.

Window system, kernel & plumbing

These are the permanent residents. They're listed mostly so a name match reassures you — none of them is optional, and none of them is yours to manage.

• kernel_task — the kernel's own work, shown as a single row. Its famous "high CPU" episodes are often thermal management — one of its jobs, not all of them. The post explains why killing it is impossible and misreading it is easy.
• WindowServer — per its man page, "provides various UI services such as window management, content compositing, and event routing": what you see on screen is composited here. Its load scales with what's happening visually; sustained high load pairs naturally with the thermal-throttling question.
• launchd — PID 1, the "system wide and per-user daemon/agent manager". Every daemon and agent on this page descends from it — the exceptions are launchd itself and kernel_task, which is the kernel.
• logd — manages the unified logging system's historical data, per its man page. When processes log heavily, logd is the one writing it down — sometimes a useful tell.
• watchdogd — "ensures that the system is healthy and able to make forward progress", per its man page: the daemon whose timeout you meet in certain panic reports.
• distnoted — distributed notifications: the system's internal message board. Ubiquitous, tiny, occasionally chatty.
• cfprefsd — preferences reads and writes for apps that use the CFPreferences/NSUserDefaults APIs, per its man page.
• notifyd — the low-level notification server (the notify(3) API, not your notification banners).
• diskarbitrationd — notices disks appearing and disappearing and governs mounting. Involved every time you plug in or eject a drive.

When a daemon actually deserves attention

The honest checklist is short. A process usually deserves your time when all three line up: the load is a plateau, not a settling burst; a physical symptom agrees with it — sustained heat, fans that never spin down, overnight battery drain, a disk writing constantly; and the timing has no innocent explanation (no recent update, import, migration, or first login). One signal alone is more often noise than not; two deserve a look; all three together justify a real investigation. And one severe warning — a SMART error, a kernel panic — is its own reason to act regardless of the checklist. Start from the daemon's own post above, and if the machine's overall health is the worry, the "is my Mac dying" checklist is the wider frame.

And a word on malware, because every process-name search eventually lands there: every name in this directory is a normal part of macOS. Malware on a Mac is real but it is not usually hiding behind Apple's daemon names in Activity Monitor — Apple's own layered protections (Gatekeeper, notarization, XProtect) are documented in the Platform Security guide, and the daemons enforcing them are in the security section above. A scary name is not a signal. A plateau with symptoms is.

Where CoreGuard fits

This page is the manual approach: name, job, shape, symptom. CoreGuard watches the same signals over time on your Mac — thermals, battery behavior, per-app disk writing — shows you the top process live, and when a write rate turns abnormal, its free warning names the process responsible, in plain English, without ever cleaning or optimizing anything. The danger-visibility layer is free, and it stays free: knowing something is wrong is never the paid feature. And it makes no network connections of any kind — the readings happen on your Mac and stay there.

Frequently asked questions