photolibraryd, and the other daemons your Photos library keeps busy

By CoreGuard · Aug 13, 2026 · 13 min read

What is photolibraryd on a Mac?

photolibraryd is the macOS photo library agent. Its own man page is two sentences long: "photolibraryd is the photo library agent. It handles all photo library requests." It lives at /System/Library/PrivateFrameworks/PhotoLibraryServices.framework/Versions/A/Support/photolibraryd, runs as the per-user LaunchAgent com.apple.photolibraryd, and it is the process that reads and writes your Photos library on behalf of everything else — Photos itself, the Finder's Quick Look, the Photos widget, apps that ask for your pictures.

That "on behalf of" is the whole point, and it is why the daemon exists at all rather than each app opening your library directly.

Why a broker exists at all

Here is the argument in one command. On the Mac this article was written on, an ordinary shell — with no special permissions — cannot even list the Photos library:

$ ls ~/Pictures/"Photos Library.photoslibrary"
ls: /Users/…/Pictures/Photos Library.photoslibrary: Operation not permitted

The directory exists and is owned by my user; the refusal comes from macOS privacy protection, which treats the Photos library as protected data — tccd's department, the consent broker that decides which app may touch what. What follows is the standard reading of the architecture rather than something one refused ls can prove: an app that wants your pictures doesn't open files — it asks, and photolibraryd, "the photo library agent" that "handles all photo library requests," is who it asks. One agent fronts the library and answers on everyone's behalf.

Two useful consequences follow. Seeing photolibraryd busy right after you open an app that shows photos is expected — that's the request path working. And a photos-related app that seems stuck while photolibraryd works hard is usually waiting on the library, not broken.

The five processes, and what each one owns

Apple documents these thinly — the man pages for photolibraryd and photoanalysisd are dated November 2, 2016, and cloudphotod's and mstreamd's December 18, 2018, in a macOS 26 install. Short as they are, they're the authoritative statements of purpose, so here they are with what each daemon actually does day to day.

• photolibraryd — "handles all photo library requests." The library's gatekeeper and bookkeeper: opening it, keeping its database consistent, serving reads and writes. Gets busy when you browse, import, edit, delete, or when an app requests photos.
• photoanalysisd — per its man page, "background processing of photo libraries for Memories, People and scene or object based search." This is the one that runs for hours after a big import and makes fans audible. It has its own deep dive.
• cloudphotod — "the iCloud Photos agent. It is responsible for all iCloud Photos activity." Uploads, downloads, and the local-versus-iCloud state of every asset. Busy on a first sync, a big import, or when Optimize Mac Storage fetches originals.
• mstreamd — "responsible for My Photo Stream and Shared Albums for Photos," per its man page. Wasn't running here at all — consistent with a Mac that uses neither.
• mediaanalysisd — Live Text and Visual Look Up. Notably it has no man page, and it is system-wide rather than Photos-only, which is exactly why it also shows up when you've never opened Photos.

Four of the five — photolibraryd, photoanalysisd, cloudphotod and mediaanalysisd — were observed running on this Mac with Photos closed; mstreamd wasn't, which fits its job (no Shared Albums in use here). Daemons running with the app closed is normal, and it is a big part of why people search for these names.

One correction worth making explicitly, because several pages that rank for this daemon get it wrong: photolibraryd does not do face recognition or object detection. Apple's man pages assign that work — "Memories, People and scene or object based search" — to photoanalysisd. If a page tells you photolibraryd is "scanning your faces", it has the wrong daemon.

Read their launchd contracts yourself

This is the part no listicle will tell you, and it takes one command per daemon (one label is irregular: mstreamd's job file is com.apple.mediastream.mstreamd.plist, not com.apple.mstreamd.plist):

$ plutil -p /System/Library/LaunchAgents/com.apple.photolibraryd.plist   # excerpt
  "KeepAlive" => { "Crashed" => true }
  "ProcessType" => "Adaptive"
  "EnablePressuredExit" => true
  …

Three facts fall out of that, and each one answers a question people actually ask:

• KeepAlive only on Crashed — launchd doesn't hold photolibraryd up unconditionally; it brings it back if it crashes, and otherwise starts it when something asks. So "I quit it and it came back" is the contract working, not a fight you can win.
• ProcessType Adaptive (photolibraryd) versus Interactive (photoanalysisd) — these tell the system how to schedule each one. The analyzer is allowed to behave like foreground work; the library agent adapts.
• EnablePressuredExit on all of them — macOS may ask these processes to exit when memory is tight. This is consistent with what I observed: cloudphotod present in my first sample, absent in the second, back in the third — no exit reason captured, but exactly the pattern this setting permits. A Photos daemon vanishing from Activity Monitor is not automatically a crash.

These jobs also register scheduled work of their own — photolibraryd's plist carries two repeating Maintenance tasks (a curated-library pass every three hours, periodic maintenance daily). cloudphotod's is the one worth showing, because it connects two things people usually treat as unrelated:

$ plutil -p /System/Library/LaunchAgents/com.apple.cloudphotod.plist   # excerpt
  "LaunchEvents" => { "com.apple.bg.system.task" => {
      "com.apple.cloudphotod.configurationrefresh" => {
        "Priority" => "Maintenance"
        "RepeatingTask" => { "Interval" => 43200, … }
        "RequiresNetworkConnectivity" => true } … } }

cloudphotod registers a repeating maintenance activity — every 43,200 seconds, twelve hours — with the system's background-task machinery, marked Maintenance priority and requiring network connectivity. That's the deferred-scheduling world our dasd post covers: such activities run when the system decides conditions are right, not on a visible timer. When people say iCloud Photos "does things at random times", this is the mechanism they're describing.

The second library you didn't know you had

photolibraryd's man page scopes it to photo library requests, and — my observation, not Apple's wording — the libraries it fronts are plural. Beyond ~/Pictures/Photos Library.photoslibrary there is a second one most people have never seen: ~/Library/Photos/Libraries/Syndication.photoslibrary. It exists on the Mac used for this article, and it is TCC-protected the same way (du on it: "Operation not permitted"). Howard Oakley examined it on macOS 26 in December 2025: it holds the photos, videos and stickers you've received in Messages — that's how they show up in Photos — and it duplicates content that also lives under ~/Library/Messages/Attachments/.

A correction to advice circulating on forums first: this is not the Shared Albums library, and Oakley warns plainly that deleting it will likely destroy the images and videos in your Messages history — so don't. And it can matter: Oakley notes users reporting Syndication libraries "of huge size, sometimes tens of GB". In an October 2023 thread, a poster whose photolibraryd had ballooned to 50 GB of memory traced the problem to this library and deleted it — before Oakley's warning existed, and calling it a library "for shared albums", the very misreading corrected above; whether Messages media was lost went unrecorded. And one 118 GB Photos.sqlite-wal write-ahead log has been reported inside it (August 2025, on Monterey 12.7.6 and a 2015 MacBook Pro — an old OS, not evidence about current macOS). If Photos-related processes look busy and your main library is small, this second library is worth knowing about — as a fact to weigh, not a folder to delete.

Whose work is it? Telling them apart

The names are similar enough that the wrong one gets blamed constantly. A quick discriminator:

• Hours of CPU after importing photos, no network involved → photoanalysisd. It's building Memories, People and searchable scenes.
• Sustained network plus disk, especially on a new Mac or a new library → cloudphotod. It's moving originals in or out of iCloud.
• Bursts while you scroll, edit, import or delete, settling when you stop → photolibraryd answering requests.
• Busy when you never opened Photos at all → look at mediaanalysisd first (Live Text, Visual Look Up) — it serves the whole system, not just your library.
• Only when Shared Albums are in play → mstreamd.

None of that requires a tool. It requires reading the right row: sort Activity Monitor by CPU, then check the Network and Disk tabs for the same process, and watch whether the load trends down over an hour.

For scale, one documented Catalina-era case is old but instructive: a Catalina-era thread (2019–2020) recorded cloudphotod sustaining ~100 MB/s of writes, with individual Macs logging 1.4–1.8 TB written before the thread ended, unresolved, in mid-2020. Nothing like that is a documented pattern on current macOS — but it is exactly the kind of event an SSD host-write counter remembers, which is why "which process is writing" is worth being able to answer.

When it deserves attention

Same rule as every other daemon on this site: judge the shape, not the peak. The complaint history for this family clusters visibly after major macOS upgrades — High Sierra in 2017, Catalina in 2019–2020, Ventura and Sonoma in 2023 — and the standing advice in a January 2026 Apple Communities thread about Tahoe 26.2 says the same thing: processes like photolibraryd and photoanalysisd "would be expected to do that for maybe a few hours or days after installing an OS update." Heavy work that settles by itself after an import, an upgrade, or a first iCloud sync is the system doing its job — the analysis and sync passes are genuinely large jobs on a big library. A plateau is different: the same process, the same load, for days, with a physical symptom attached — sustained heat, fans that never spin down, overnight battery drain, a disk writing constantly. That combination earns an investigation.

What isn't a useful move: force-quitting these in a loop. photolibraryd returns on the next request (that's the contract above), the analysis queue survives, and you've thrown away the timeline that would have told you which of the five was actually working. The "disable it with launchctl" recipes that rank for these searches carry costs their authors rarely state: the persistent variants require disabling System Integrity Protection, the result breaks Photos search and People, and the setting tends to quietly revert. That's a poor trade for a daemon whose job is answering requests.

If you suspect the library itself, Apple's supported route is the Photos repair tool — hold Option and Command while opening Photos — which "analyzes the library's database and repairs any inconsistencies". Back up first. And one migration fact worth knowing before a major upgrade, documented so far only in forums (no Apple advisory): upgrading to Tahoe migrates the Photos library database to a format older macOS can't read — plan a downgrade as if the library won't open afterwards. The wider health checklist is the frame if you're worried about the machine rather than the app.

How to tell which Photos daemon is busy

1. Get the exact name. In Activity Monitor choose View → All Processes and sort by % CPU. photolibraryd, photoanalysisd, cloudphotod, mstreamd and mediaanalysisd are five different answers — the spelling is the diagnosis.
2. Check the other tabs for that same process. Network activity points at cloudphotod's work; heavy disk with no network points at analysis or library work. This is the step that stops people blaming the wrong daemon.
3. Read its contract. plutil -p /System/Library/LaunchAgents/com.apple.<name>.plist shows KeepAlive, ProcessType and any scheduled repeating tasks — read-only, no changes, no sudo. (mstreamd is the odd one out: its file is com.apple.mediastream.mstreamd.plist.)
4. Watch the trend over an hour, not a second. Settling after an import or a sync is expected; a flat plateau across days with heat or drain attached is the case worth pursuing.

Where CoreGuard fits

CoreGuard is an honest, local-only Mac health monitor — it observes and explains, and never cleans or optimizes. For a family like this it does the boring part continuously: live CPU, temperature and fan readings with the top process named in plain English, plus a per-minute history of system CPU, memory and temperature, so "is this settling or is it a plateau" becomes something you can see rather than guess. It doesn't touch your Photos library, and it makes no network connections of any kind. Danger visibility is free and stays free.

Frequently asked questions