What Is bird on Mac? 50 Calls a Day, 0 Bytes Written

bird is the macOS daemon behind iCloud Drive. Apple's own man page calls it "one of the system daemons backing the Documents in the Cloud feature" and says you should not run it yourself. On my Mac mini it has run for 22 days and used 37.4 seconds of CPU, about 0.002% of one core, number 191 of 625 processes. It has written 0 bytes to disk in that time. That is because no Apple Account is signed in on this Mac, so there is nothing to sync. It still did not sit idle. In the last 24 hours 50 connections came in from other processes asking about iCloud Drive. The answer bird gives here is Logged out - iCloud Drive is not configured.

Below is what bird is, who called it in one day and why, what the brctl tool that talks to it still accepts on macOS 26, and what people actually do when bird pins a core.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), up 22 days, with no Apple Account and no iCloud Drive. That makes this the quietest bird you can get. Read my numbers as a floor, not as a typical Mac. I measured everything on 2026-10-20 as an admin user, without sudo.

What bird is

$ ps -axo pid,etime,time,rss,command | grep [/]bird
  947 22-06:13:19   0:37.44  11424 /System/Library/PrivateFrameworks/iCloudDriveCore.framework/Versions/A/Support/bird

$ man bird
     bird - Documents in the Cloud
     bird is one of the system daemons backing the Documents in the Cloud
     feature.
     There are no configuration options to bird, and users should not run bird
     manually.
SEE ALSO
     brctl(1)

The binary is 146,992 bytes, universal (x86_64 and arm64e), inside the private iCloudDriveCore framework. It runs as a per-user LaunchAgent, /System/Library/LaunchAgents/com.apple.bird.plist (2,595 bytes), not as root. If that distinction is new, LaunchAgent vs LaunchDaemon covers it. The plist has no KeepAlive key, so launchd starts bird when something asks for one of its five Mach services (com.apple.bird, .token, .push, .cache-delete and a notifications delegate) and lets it exit under memory pressure. launchctl print shows a soft memory limit of 100 MB. Mine has a 5.2 MB footprint and peaked at 5.8 MB.

bird is the local half of iCloud Drive. The network half is cloudd, the CloudKit daemon that does the actual uploads and downloads. Since macOS Sonoma, iCloud Drive also runs through Apple's FileProvider framework, and fileproviderd handles a lot of what bird used to do. Howard Oakley, who traced the Sonoma change, put it this way: "Involvement of traditional iCloud subsystems such as CloudDocs is now minimal." CloudDocs is bird's internal name. Its error domain is BRCloudDocsErrorDomain, and brctl describes itself as the tool to "Manage the CloudDocs daemon."

Daemon (same rig, same uptime)	Disk read	Disk written	Footprint
bird	130.0 MB	0.0 MB	5.2 MB
fileproviderd	56.6 MB	0.1 MB	5.9 MB
cloudd	163.4 MB	27.5 MB	10.3 MB
suggestd (for scale)	376.9 MB	5.6 MB	13.8 MB

About 98% of bird's CPU time ran at background QoS, the lowest scheduling class that still gets work done. On a Mac with an account, the folders bird manages are ~/Library/Mobile Documents (the real iCloud Drive) and ~/Library/Application Support/CloudDocs (its database). Neither exists on this Mac.

What bird does with no account

The plist registers five background jobs. launchctl print gui/501/com.apple.bird shows four live triggers, and one of them is not in the plist at all:

Trigger	In plist	Live	Schedule
memory-reclaimer	no	yes	every 6 h, on power
configuration-server-update	yes	yes	every 48 h, on power
apps.install / apps.uninstall	yes	yes	when an app is registered or removed
app-telemetry	yes	no	every 48 h, user idle
analytics-report	yes	no	every 24 h, user idle

The memory reclaimer ran 4 times in the 24 hours, once every six hours as scheduled. At 17:35 the configuration job did go to the network. It logged downloading iCloud Drive configuration, the request finished successfully, and then bird failed to save it: config: failed to move downloaded cache file into place ... "No such file or directory". So even a Mac that has never had iCloud Drive pulls Apple's iCloud Drive configuration every two days. It then fails to store it, probably because the folder it writes to was never created. bird is also one of the two clients that nsurlsessiond names in its two-hourly power log lines here, and it has an empty staging folder in nsurlsessiond's cache.

Who called bird in one day

I pulled bird's unified log for the last 24 hours with /usr/bin/log show --predicate 'process == "bird"' --last 24h --info --debug, which returned 8,192 lines. If you have never used that tool, the log show command has the basics. Every incoming client shows up as an XPC line like activating connection ... name=com.apple.bird.peer[9473]. There were 50. The log only gives a PID, and PIDs get reused within a day. My first pass matched each PID to the first process that ever logged under it, and that tagged three connections as git, gh and node. When I matched each PID to whatever logged under it within 30 seconds of the connection, all three turned out to be the Shortcuts runner. The corrected count:

• BackgroundShortcutRunner, 34 connections. This is the Shortcuts background runner. Eleven calls landed every two hours at about :48, and the rest came in clusters (four between 19:19 and 19:54, eight between 12:03 and 12:07). shortcuts list on this Mac returns zero shortcuts. Its own logs are mostly about resolving action metadata and bookmarks, not about running anything I set up. Each call made bird log the same line, accounts/accounts-with-types-sync, nine times. The five replies that reached the log, all after 15:25, carried error code 2.
• XProtect remediators, 14 connections. Between 23:48 and 23:51 fourteen of Apple's malware remediators (Adload, Pirrit, SnowBeagle, Bundlore and ten others) each opened a connection. That is the nightly XProtect scan covered in how to run XProtect on a Mac. Those four minutes produced 7,614 of bird's 8,192 log lines, 93% of the day.
• brctl, 2 connections. That was me, probing the tool described next.

The error code is readable once you ask brctl directly: BRCloudDocsErrorDomain Code=2 "Logged out - iCloud Drive is not configured". So on a Mac with no account, bird's day is mostly other system processes asking whether there is an iCloud Drive, and bird telling them no.

brctl on macOS 26: what still works

brctl is the command-line client for bird. Guides recommend brctl download to force files down and brctl evict to free local space, for example this January 2026 walkthrough. Other sources say those commands are gone: the icloud-pull project states that Apple "removed this subcommand in recent macOS versions." The man page and the built-in help disagree too. man brctl (dated 2014) lists seven commands. brctl -h lists seven different ones. Only four are on both lists.

My first test said download, evict and versions were dead. All three printed No such operation and exit 64. That was my bug, not Apple's. I had looped over strings like "download /tmp/x" in zsh, which does not split an unquoted variable into words. So brctl received the whole thing as one argument, and an invented command like brctl bogus produces the same error. Passed as real arguments, every command on both lists is accepted:

Command	man page	brctl -h	Result here (no account)
download	yes	no	accepted; Code=2 "Logged out - iCloud Drive is not configured"
evict	yes	no	accepted; Code=6 "Path is outside of any CloudDocs app library, will never sync"
versions	yes	no	accepted; FileProvider: no valid file provider for the URL
log	yes	yes	works; -w streams, --last 1m -q prints
monitor	yes	yes	accepted; "not in a synced location"
dump	yes	yes	accepted; Code=141 "Access denied"
diagnose	yes	yes	listed (not run, it collects a large bundle)
status	no	yes	accepted; Code=141 "Access denied"
accounts	no	yes	empty output, exit 0
quota	no	yes	empty output, exit 0

$ brctl download /tmp/brctl-probe.txt
brctl: Unable to start downloads: Error Domain=BRCloudDocsErrorDomain Code=2
"Logged out - iCloud Drive is not configured"

$ brctl evict /tmp/brctl-probe.txt
brctl: Unable to evict item at path '/tmp/brctl-probe.txt': Error Domain=BRCloudDocsErrorDomain
Code=6 "Path is outside of any CloudDocs app library, will never sync"

So on 26.4.1, download and evict have not been removed from brctl. They are hidden from its help, and the binary still parses them and passes them to bird. What I cannot show from this Mac is whether they actually download or evict a file, because there is no iCloud Drive to act on. The command that really did lose evict is a different tool: fileproviderctl, as reported on Apple's developer forums. On this Mac its help lists only dump, diagnose, evaluate, check/repair and obfuscate. If brctl evict fails for you on a real iCloud file, Finder's Remove Download is the fallback. Several Sonoma-era reports say it only appears when Optimize Mac Storage is on.

Why bird uses so much CPU

None of the above explains the thing people search for, which is bird at 100% for hours. I can't reproduce that here. The pattern in reports is consistent, though: bird gets stuck on a sync it can't finish.

• The longest-running Apple Community thread, "bird" process is taking over, dates from Yosemite in 2014 and has 990 "Me too" votes. Force-quitting did not help, because bird came straight back. Turning iCloud Drive off made it stop, and one person who re-enabled it later avoided a repeat by uploading in small batches.
• A June 2025 developer forums post describes an M4 MacBook Pro on Sequoia 15.5 where "EtreCheck report shows consistent high CPU usage from bird" and the logs said it was waiting on a local metadata index. The poster had tried killall bird, Safe Mode, toggling iCloud Drive, and signing out and back in. There was no answer.
• On Hacker News, the advice that comes up is the opposite of the 2014 thread. One commenter says that when iCloud gets stuck, killall bird "usually gets it syncing again pretty much instantly," and another lists it as the second of three tips, along with turning on Finder's status bar to watch progress.

These don't conflict. Killing bird restarts the sync, which clears a stall but not a file that will stall it again.

What to do about it

1. Look before you kill. Turn on Finder's status bar (View > Show Status Bar) to see iCloud progress, and run brctl log -w in Terminal. It streams bird's log live, so you can see which item it keeps retrying.
2. Restart it. killall bird is safe. With no KeepAlive, launchd starts it again on the next request, the same on-demand behavior I describe in killall Dock on a Mac. If the CPU comes back right away, the stuck item is still there.
3. Move the problem file. If brctl log -w keeps naming the same item, moving that one item out of iCloud Drive is less drastic than the next step. The 2014 thread's lasting fix was uploading in small batches instead of all at once.
4. Toggle iCloud Drive last. In macOS 26 the switch is under System Settings > [your name] > iCloud > Drive, per Apple's iCloud Drive guide. Turning it off can remove local copies of cloud-only files, so make sure anything you need is downloaded first.

If bird is quiet but iCloud is still slow, look at the network side in what cloudd does. For another daemon that is mostly answering "nothing here" on an account-less Mac, see suggestd.

FAQ

What is bird on Mac?

bird is the macOS daemon that backs iCloud Drive (internally called CloudDocs). It tracks which files in iCloud Drive need to be uploaded, downloaded or evicted, and works with cloudd, which does the network transfer, and fileproviderd, which presents the files in Finder. It runs as a per-user LaunchAgent from the private iCloudDriveCore framework and starts on demand.

Is it safe to kill bird?

Yes. killall bird or Force Quit in Activity Monitor does not delete files. macOS starts bird again the next time something asks for iCloud Drive. That often clears a stuck sync, but if one file keeps failing, CPU use returns until that file is moved or the sync finishes.

Does brctl download still work on macOS 26?

The command still exists. On macOS 26.4.1 brctl download and brctl evict are missing from brctl -h but are still accepted and passed to bird. On a Mac with no iCloud account they return "Logged out - iCloud Drive is not configured." The tool that lost its evict command is fileproviderctl, not brctl.

Measured on 2026-10-20 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, up 22 days, no Apple Account, no iCloud Drive), as an admin user without sudo. CPU, memory and disk counters come from ps and proc_pid_rusage for bird and three other daemons; the job list from launchctl print and the LaunchAgent plist; the day of activity from one /usr/bin/log show capture of the bird process (8,192 lines, 18:48 on 10/19 to 18:00 on 10/20). Callers were identified by matching each peer PID to the process that logged under it within 30 seconds, after a first PID-only pass misattributed three. brctl results come from running each of the ten commands in its man page and help with real word-split arguments against a file in /tmp; a first run with zsh-quoted arguments gave false "No such operation" results and is discarded. I could not test download or evict on a real iCloud file. User reports come from one Apple Community thread, one Apple developer forums thread and two Hacker News comments; the settings path is from Apple's macOS 26 user guide.