What Is cloudd on Mac? One Disk Mount, 54 iCloud Checks

cloudd is the CloudKit daemon on a Mac: the background process that Apple's own apps and system services go through when they read or write data in iCloud. On my Mac mini it runs twice, once as root and once as my user, and it keeps working even though no Apple Account is signed in. Over the last 20 hours of log it checked access for 53 different iCloud containers, from Messages and Screen Time to Find My and Apple Pay. Most of those checks (217 of 270) came in four bursts. When I mounted a 10 MB disk image to test one cause, cloudd checked 54 containers in 0.48 seconds. Mounting it again a minute later produced nothing.

So "what is cloudd" has a short answer and a more useful one. The short answer is CloudKit. The useful one is that the log tells you which app is asking cloudd for something, and that is what you need when it uses a lot of CPU.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), up for 21 days, measured on 2026-10-19 as an admin user without sudo.

Two cloudd processes, both from launchd

$ ps -axo pid,user,time,etime,command | grep [c]loudd
  775 root      0:13.86 21-07:43:10 .../CloudKitDaemon.framework/Support/cloudd --system
  870 sg-mini   0:48.55 21-07:43:08 .../CloudKitDaemon.framework/Support/cloudd

The binary lives in /System/Library/PrivateFrameworks/CloudKitDaemon.framework, which is where the name comes from. CloudKit is the framework Apple documents for apps that store data in iCloud (Apple's CloudKit page). Apple's own apps use it too, and cloudd is the process that does the network work for them.

The two copies come from two launchd jobs with the same label, com.apple.cloudd. If the difference between the two folders is new to you, LaunchAgent vs LaunchDaemon covers it.

Job	Runs as	Arguments	Mach services
/System/Library/LaunchDaemons/com.apple.cloudd.plist	root	--system	com.apple.cloudd.system, .system.cache-delete, cloudasset.cloudd.system
/System/Library/LaunchAgents/com.apple.cloudd.plist	your user	none	com.apple.cloudd, .cache-delete, cloudasset.cloudd

Both plists set EnablePressuredExit and EnableTransactions, so launchd can stop them when idle and start them again on demand. Here they had been up for the full 21 days anyway. Combined CPU time was 62.4 seconds, about 2.9 seconds a day. For comparison, nsurlsessiond on the same machine used about 7.4 seconds a day. With no account signed in, cloudd is close to idle.

What cloudd does when there is no Apple Account

I pulled every cloudd line still in the unified log: 8,355 lines, earliest 2026-10-11 23:48. Retention is uneven. 10/12 to 10/17 keep only 96 to 356 lines a day, while 10/19 alone has 5,389, so the full detail covers about 20 hours (2026-10-18 23:15 to 2026-10-19 19:18). The counts below come from that window.

• 294 × "Could not create primary backing account" (Error level). This is cloudd finding no iCloud account to work with. 270 came from the user copy, 24 from the root copy.
• 270 × "TCC approved access for container …". Before each request, cloudd asks the privacy system (TCC) whether the calling app may use that container. Every check here was approved. None were denied.
• 23 × "This request requires an authenticated account", ending in CKInternalErrorDomain Code=1002. 21 of them followed a Messages request (com.apple.messages.cloud from imagent), about once an hour.
• 26 responses with status 200. Not every request needs an account. triald, Apple's feature-rollout daemon, fetched its Sync.fetch.RampState records, and cloudd logged "Created anonymous account" 4 times, for triald, Messages and UsageTracking. The 35 response-size lines in the capture add up to 2.96 MB.

Outside the bursts, the steady traffic is small: 53 container checks in 20 hours. Messages and Screen Time's UsageTracking accounted for 21 each, and triald for 6. The hourly Messages attempt fails every time, because there is no account behind it.

The bursts: CacheDelete asking how much space cloudd can free

The four bursts landed at 23:49, 12:03, 13:35 and 14:48. Each one checked 54 or 55 containers. Three of them finished in under half a second; the 13:35 one stretched to 36 seconds. Just before each burst, both cloudd processes accepted a connection on their cache-delete service from PID 967, which is /System/Library/PrivateFrameworks/CacheDelete.framework/deleted.

deleted is the daemon that tracks purgeable space, the storage macOS can reclaim when a disk fills up. At 12:03:29 its own log says why it called:

deleted: [com.apple.cache_delete:daemon] Disk mounted at <private>, sending purgeable updated notification: CACHE_DELETE_PURGEABLE_UPDATED

That fits: the 12:00 and 13:30 runs that day both mounted vendor disk images (EyeTV and HDHomeRun, then Pioneer DJ drivers) to check which CPU architectures the installers support. So I tested it directly with a blank 10 MB HFS+ image:

hdiutil create -size 10m -fs HFS+ -volname cdprobe -o probe.dmg
hdiutil attach probe.dmg -nobrowse -mountpoint ./mnt
sleep 20; hdiutil detach ./mnt
/usr/bin/log show --info --start "$T0" \
  --predicate 'process == "cloudd" OR (process == "deleted" AND eventMessage CONTAINS "mounted")'

The first mount reproduced a burst exactly: 54 container checks and 58 "Could not create primary backing account" lines, from 19:32:48.42 to 19:32:48.90. deleted logged a SLOW purgeable query with CACHE_DELETE_NO_CACHE = 1 before calling out. The user cloudd's CPU time went from 48.55 to 48.74 seconds and the root copy's from 13.86 to 13.87, so the burst cost about 0.2 seconds of CPU.

The repeats did nothing. I mounted the same image twice more, 21 and 51 seconds after the first unmount, then a new APFS image 25 seconds after that. deleted logged "Disk mounted" each time, but it did not run the slow query, and cloudd logged 0 lines. My reading is that deleted caches the purgeable answer and only asks cloudd again after some interval. I did not measure how long that interval is. The real bursts were 73 to 92 minutes apart. Not every burst followed a mount either: the 14:48 and 23:49 ones have no "Disk mounted" line before them, and 23:49 falls inside the nightly window when XProtect's scans start on this machine (how to run XProtect on Mac has that schedule). I can't tell from the log what made deleted ask at that time.

How to find which app is behind cloudd

If cloudd is using a lot of CPU, the container names tell you which app is driving it. On this machine they were all Apple services; on a Mac with an account and third-party sync apps, you would also see those apps' containers. Use the full path to log, because in zsh a bare log is a shell built-in (the mac log show command covers that and the predicate syntax):

/usr/bin/log show --last 2h --predicate \
  'process == "cloudd" AND eventMessage CONTAINS "TCC approved"' \
  | grep -o 'containerID=[^:]*' | sort | uniq -c | sort -rn | head

A container that shows up hundreds of times an hour, when everything else shows up a few times, is your suspect. That is how the one well-documented high-CPU case on Ask Different was solved. The asker found cloudd making requests "in a tight loop" for SafariBookmarksSyncAgent. Turning off Safari in iCloud on every device and deleting both Safari entries in iCloud storage fixed it (Ask Different, question 463785). That is one report, not a general fix.

Across Ask Different, the Stack Exchange API finds 8 questions with "cloudd" in the title. The most viewed by far, at 234,514 views, is the 2015 prompt "cloudd wants to use the Local items keychain" (question 172247). Its accepted answer says the request is safe to allow and points to a damaged keychain when the prompt keeps coming back. The other seven ask about crashes, iCloud setup errors, sync failures, bandwidth throttling, unknown connections and high CPU, with 103 to 7,003 views each.

What I did not do: I did not kill cloudd, sign in to an Apple Account, or try to read ~/Library/Caches/CloudKit, which returns "Operation not permitted" even to ls from this shell. If your cloudd is busy because you have a real account syncing Photos or iCloud Drive, my numbers are a floor, not a comparison. The same goes for apsd, which carries the push notifications that wake many of these iCloud clients.

FAQ

What is cloudd on Mac?

cloudd is the CloudKit daemon. It runs from /System/Library/PrivateFrameworks/CloudKitDaemon.framework and does the network work when Apple's apps and system services read or write iCloud data. macOS starts two copies through launchd: one as root with --system, and one as the logged-in user.

Is cloudd a virus?

No. cloudd is part of macOS, launched by /System/Library/LaunchDaemons/com.apple.cloudd.plist and /System/Library/LaunchAgents/com.apple.cloudd.plist. Its binary sits on the read-only system volume. A process named cloudd running from anywhere else would be worth investigating.

Why is cloudd using so much CPU?

Usually one app is asking it for iCloud data over and over. Count the containerID values in its TCC log lines with /usr/bin/log show and look for the one that dominates. Short bursts are normal: on a test Mac mini, a disk mount made the CacheDelete daemon query cloudd, which checked 54 containers in under half a second.

Find My was one of the containers cloudd checked. The daemon that does the Find My network work itself is a separate one: what searchpartyd does on a Mac with Find My off, measured on the same machine.

Measured on 2026-10-19 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, up 21 days), no Apple Account signed in, as an admin user without sudo. Process and CPU figures are from ps. The log counts come from one /usr/bin/log show --info --last 16d capture of the cloudd process (8,355 lines, earliest 2026-10-11 23:48; full detail only from 2026-10-18 23:15). The mount test used blank 10 MB HFS+ and APFS images attached with -nobrowse, four mounts in total, and only the first produced a cloudd burst. I did not measure how long deleted caches its answer. Community counts are from the Stack Exchange API on 2026-10-19. CloudKit background is from Apple's developer page.