I Found bird in Activity Monitor. Here’s the Paper Trail.

bird is Apple’s iCloud Drive daemon, but it rarely works alone. Here is how it relates to cloudd and fileproviderd, why it gets busy, and how to test whether sync is progressing.

By CoreGuard · Jul 24, 2026 · 16 min read

What is bird on Mac?

bird is Apple’s per-user iCloud Drive daemon for “Documents in the Cloud.” It handles the local side of that Documents-in-the-Cloud layer — the uploads, downloads, and local iCloud Drive state involved in keeping your documents in sync. It is a normal macOS component, and high CPU by itself does not make it malware.

Apple’s bird(8) manual page, mirrored from the manual shipped with Apple’s developer tools, says: “bird is one of the system daemons backing the Documents in the Cloud feature.” It also says there are no user configuration options and that users should not run it manually. Its “See Also” points to brctl(1), Apple’s CloudDocs control and diagnostic utility.

On current macOS, bird runs for each signed-in user as the LaunchAgent com.apple.bird. Its executable is:

/System/Library/PrivateFrameworks/iCloudDriveCore.framework/Versions/A/Support/bird

That location matters. A process merely named bird is not enough to establish identity; the framework path, launch identifier, and Apple platform-binary signature are the useful evidence.

The name is vintage Apple: short, opaque, and almost engineered to look suspicious in Activity Monitor. Its actual job is much less theatrical. It is iCloud Drive doing paperwork.

bird vs cloudd vs fileproviderd: who does what?

These processes can become active together because they occupy different layers of the same cloud-file operation. Treating them as interchangeable loses the most useful clue.

• fileproviderd is the broker. Apple’s File Provider system presents cloud-backed files to Finder and other apps, coordinates domains, and helps materialize files that are currently stored remotely. Modern iCloud Drive is one of those File Provider domains. I cover the broker and provider-attribution problem separately in the fileproviderd explainer.

• bird handles the Documents-in-the-Cloud layer. Its bird(8) role is tied to iCloud Drive documents and the iCloud Drive state for the signed-in user. If you enable Desktop & Documents, move a large folder into iCloud Drive, or request an iCloud-only file, bird is a plausible participant.

• cloudd is the CloudKit daemon. Apple’s cloudd(8) manual page, also mirrored from Apple’s shipped manual, says: “cloudd is the system daemon backing the CloudKit feature.” CloudKit carries structured app and user data through iCloud containers, so cloudd can serve many clients beyond iCloud Drive.

cloudd can run in both the system launch domain and the signed-in user’s launch domain, using com.apple.cloudd in each. Seeing a system instance and a per-user instance is therefore normal. It is not proof that the daemon duplicated itself or that two unrelated programs have borrowed the name.

A useful mental model is:

Finder or app → fileproviderd → bird + cloudd → iCloud

That is a responsibility map, not a literal packet trace. fileproviderd brokers access to the cloud-backed domain, bird handles the Documents-in-the-Cloud layer, and cloudd provides the broader CloudKit service layer. The exact work can overlap, branch, and happen asynchronously.

There is a useful reported example. In an Apple Developer Forums thread, a user reported that macOS 26.1 Open and Save panels lagged by roughly one second per folder click while fileproviderd, cloudd, bird, and siriactionsd showed CPU spikes together. An Apple DTS engineer identified the underlying behavior as a known issue. That report proves the processes can participate in one visible incident; it does not prove that every simultaneous spike has the same cause.

Why is bird using high CPU?

There is no universal bird CPU percentage above which iCloud Drive becomes “stuck.” Macs have different core counts, sync sets, network conditions, free-space pressure, and amounts of work queued. A cutoff without context would be numerology with a percentage sign attached.

The useful approach is to treat each cause as a hypothesis and test it against visible sync progress.

A large or first-time sync. Signing into iCloud on a Mac, enabling iCloud Drive, or turning on Desktop & Documents can create a substantial reconciliation job. macOS must compare local and remote state, resolve metadata, and upload or download what is missing.

Materializing cloud-only files. With Optimize Mac Storage enabled, some files may exist primarily in iCloud until an app requests them. Apple’s iCloud Drive documentation describes how macOS keeps files available on demand. Fetching those files can involve fileproviderd, bird, disk activity, and network traffic.

Evicting local copies. The reverse operation also requires bookkeeping. When macOS removes a local download while retaining the iCloud copy, the file’s state changes even though the document remains visible in Finder.

A folder that keeps changing. Build output, export jobs, automated file generation, mass renames, or an app repeatedly rewriting files inside iCloud Drive can keep producing fresh work. In that case, bird may be behaving correctly while the upstream folder never becomes quiet.

A stuck or repeatedly retried item. One file with an upload, permission, naming, or state problem can be reconsidered over and over. Look for a Finder status that does not advance, a recurring error badge, or the same folder remaining in “Waiting to Upload.”

Reconciliation after a macOS update. An update can trigger metadata migration, account-state validation, or comparison of local and remote records. A post-update burst is plausible; a days-long loop with no visible progress deserves a closer look.

These are hypotheses, not verdicts. A hot bird process plus an active upload is consistent with legitimate sync. The same process remaining active while Finder shows no transfer, no changing status, and no obvious source of new files is a different pattern.

How to read bird in Activity Monitor

Open Activity Monitor, choose View → All Processes, select CPU, and search for bird. Add cloudd and fileproviderd to the investigation rather than staring at one row.

Apple’s CPU activity guide explains how Activity Monitor separates current processor activity from CPU history. For this investigation, note both the live % CPU value and whether CPU Time continues accumulating quickly. A single high sample catches a moment; a growing CPU Time value shows sustained work.

Then switch to Network. Apple’s network activity guide distinguishes accumulated data totals from current throughput. Watch whether Data Sent or Data Received changes for the relevant processes, but do not expect every byte of iCloud traffic to appear under bird. Work can be attributed across bird, cloudd, File Provider services, and other system components.

The pattern matters more than the winner of one refresh:

• bird active while Finder’s transfer indicator advances is evidence of work and progress.
• bird and cloudd active together can be an ordinary iCloud Drive sync.
• fileproviderd joining them is expected when files are being presented, downloaded, or reconciled through the File Provider domain.
• CPU falling after a transfer completes supports the sync hypothesis.
• Repeated activity with an unchanged Finder status weakens that hypothesis and raises the possibility of a retried item or blocked reconciliation.
• No network activity does not automatically mean a loop; bird may be comparing metadata, scanning local state, or waiting on another component.

Write down timestamps and observations. “It looked high earlier” is poor evidence. “Finder showed an upload, network totals moved, and CPU declined after completion” is a timeline.

Normal iCloud sync or a stuck loop?

A normal burst has a cause, visible motion, and an end. You might have just enabled Desktop & Documents, opened an iCloud-only folder, restored files, or installed a macOS update. Finder shows transfer progress or changing status icons, network totals move, and bird activity trends down as the queue clears.

A suspected loop lacks one or more of those properties. Finder may show the same item waiting without change, the same activity may return after every idle period, or CPU may remain elevated for days without any visible movement in iCloud settings or Finder. That is worth investigating, but it still is not a malware verdict.

The distinction is not “high versus low CPU.” It is progress versus repetition.

Apple documents iCloud Drive status icons such as In iCloud, Waiting to Upload, Out of Space, and the transfer-progress pie chart in Check your iCloud Drive file and folder status on Mac. Those states are closer to the actual job than Activity Monitor alone.

I would trust a high burst with a shrinking queue before I trusted a modest reading attached to an item that has failed to move since yesterday. Percentages are easy. Progress is evidence.

What to do when bird stays busy

Start with iCloud Drive’s own view of the situation. Open Finder, select iCloud Drive in the sidebar, switch to List view, and enable the iCloud Status column in View Options. Hover over iCloud Drive or open its status control to see whether macOS reports an upload, download, wait state, storage problem, or completed sync.

Next, look for an obvious trigger. Did you recently add a large folder, enable Desktop & Documents, sign into the Mac, request a cloud-only directory, restore data, or run an app that writes constantly inside iCloud Drive? A legitimate transfer should be allowed to finish if disk space and network access are healthy.

Check local free space in System Settings → General → Storage, then check iCloud storage in System Settings → Apple Account → iCloud. Local space matters because cloud-only files may need to be materialized, temporary state must be written, and a full volume can block otherwise ordinary work. iCloud capacity matters because Finder can leave items waiting when the account has no room.

Check the network without assuming that “connected” means “working well.” A congested, filtered, captive, or frequently changing connection can turn a normal transfer into repeated starts. Compare Activity Monitor’s Network tab with Finder’s transfer state.

For attribution, watch rather than intervene. Note whether Finder’s iCloud Status advances, whether Activity Monitor’s network totals for bird and cloudd keep climbing, and whether the activity lines up with something you just did — signing in, enabling Desktop & Documents, adding a large folder, or opening an iCloud-only file. Changing one variable you control — pausing the app that keeps rewriting files in iCloud Drive, or letting a known large transfer finish — is more informative, and safer, than force-quitting bird, which only restarts the work and erases the timeline.

Whatever you try, do not reach for “turn off Sync this Mac” or “sign out of iCloud” as a first move. Capture the current state and allow a plausible sync window to complete. The point is to change one reversible variable you understand, not dismantle the account configuration.

If activity remains sustained for days with no visible progress, preserve evidence: screenshots of Finder status, Activity Monitor CPU and Network views, the affected file or folder name, available storage, the time the behavior started, and whether it followed an update. That is a far better support case than a list of daemons you repeatedly killed.

Apple’s brctl tool can collect CloudDocs diagnostics, but it is a diagnostic interface, not a casual “fix iCloud” button. Start with Finder and Activity Monitor. Escalate to logs only when you have a specific stuck state to investigate.

How to verify that bird is Apple’s process

Verify identity by structure, not by how reassuring the name sounds.

For bird, the expected structure is:

• Executable: /System/Library/PrivateFrameworks/iCloudDriveCore.framework/Versions/A/Support/bird
• Launch identifier: com.apple.bird
• Launch context: per-user LaunchAgent
• Signature: Apple platform binary, with no Team ID

For cloudd, expect:

• Executable: /System/Library/PrivateFrameworks/CloudKitDaemon.framework/Support/cloudd
• Launch identifier: com.apple.cloudd
• Launch contexts: system LaunchDaemon and per-user LaunchAgent
• Signature: Apple platform binary, with no Team ID

The absence of a Team ID is not suspicious here. These are Apple platform binaries shipped as part of macOS, not ordinary third-party Developer ID applications.

Activity Monitor can show the process path through its inspection views. For a read-only Terminal check, codesign -dv --verbose=4 against the full executable path displays signing metadata, while launchctl print can inspect the corresponding service in the user or system launch domain.

A path outside the protected system framework, a different identifier, or a non-platform signature would be worth a closer look. High CPU with the correct path and identity means the genuine daemon is busy; it does not tell you whether the underlying sync is healthy.

What not to do

Do not force-quit bird, cloudd, or fileproviderd in a loop. launchd can restart them, the work queue remains, and you erase the clean timeline that would have shown whether the process was advancing.

Do not sign out of iCloud as the first move. Signing out changes far more state than the question requires and can trigger another large reconciliation when you sign back in.

Do not delete CloudDocs, CloudKit, or File Provider caches by hand because a forum comment called them “safe.” Cache directories can contain sync metadata and pending state whose meaning depends on the macOS version and account condition. Destroying that evidence is a poor diagnostic technique and can create a larger resync.

And do not call bird malware because Activity Monitor painted one row red. CPU is a symptom. Identity, trigger, progress, and duration are the evidence.

Where CoreGuard fits—and where it deliberately stops

CoreGuard can name bird as the top resource-using process in plain English while the activity is happening. That naming is live: it helps answer “what is busy now?” alongside live system CPU, temperature, and fan RPM readings.

Its persisted history is deliberately narrower. CoreGuard records a per-minute rollup of system CPU percentage, RAM percentage, and the hottest temperature reading. It does not pretend that this is a per-process history, and it does not store fan RPM in that history. If bird was busy before you opened the app, the system-level curve can show that the Mac was under load, but it cannot honestly assign every past minute to bird.

That boundary matters. Pair the live process name with Finder’s iCloud status and Activity Monitor’s CPU and Network evidence. Together they can tell a defensible story: system load rose, bird was the current top process, iCloud Drive showed an active transfer, and the load declined when the transfer completed. Without that correlation, it remains a hypothesis.

CoreGuard also provides a read-only disk-space inventory and SSD endurance and health readings, which can help expose storage pressure during an investigation. It observes and explains; it never syncs files, pauses iCloud, deletes data, or changes settings.

The app makes zero network connections. It is not an antivirus and does not label a busy Apple daemon as malicious. Every danger indication remains free; the useful distinction is still the one macOS itself gives us here: visible progress versus activity that never resolves.

How to tell whether bird is a normal iCloud sync or a stuck loop

1. Capture the baseline: Before changing anything, record the time, bird CPU usage and CPU Time, the visible Finder sync state, and any file or folder showing an error or waiting status.
2. Compare the three processes: In Activity Monitor → CPU, search for bird, cloudd, and fileproviderd; note which are active and whether their CPU Time continues growing.
3. Check network movement: Switch Activity Monitor to Network and watch whether Data Sent or Data Received changes for those processes, remembering that iCloud work can be distributed across them.
4. Inspect iCloud Drive status: Open Finder → iCloud Drive, choose List view, enable the iCloud Status column, and check the sidebar status for upload, download, waiting, storage, or error indicators.
5. Find the likely workload: Check whether you recently enabled Desktop & Documents, requested cloud-only files, added a large folder, restored data, updated macOS, or ran an app that continually changes files inside iCloud Drive.
6. Check capacity and connectivity: Verify local free disk space, available iCloud storage, and a stable network connection before interpreting repeated activity as a daemon fault.
7. Correlate with a trigger you control: Match the activity to something you just did — signing in, enabling Desktop & Documents, adding a large folder, or opening an iCloud-only file — and, if one app keeps rewriting files inside iCloud Drive, quit that app and watch whether bird settles. Change one variable at a time; do not force-quit the daemon to test it.
8. Give legitimate work time: If Finder shows progress and the activity trends down, let the sync finish; if days pass without visible progress, preserve the screenshots, timestamps, affected item, and storage state for further investigation.

Terms used in this guide

• bird: Apple’s per-user iCloud Drive LaunchAgent, identified as com.apple.bird, that backs Documents in the Cloud.
• cloudd: Apple’s CloudKit daemon, available in system and per-user launch contexts under com.apple.cloudd.
• CloudKit: Apple’s framework and service layer for storing and syncing structured app and user data through iCloud containers.
• File Provider / fileproviderd: The macOS framework and system broker that present cloud-backed file domains to Finder and other apps.
• Documents in the Cloud: Apple’s name in the bird(8) manual page for the document-sync feature behind iCloud Drive.
• brctl: Apple’s CloudDocs control and diagnostic command-line tool; its manual page points back to bird(8).
• platform binary: A binary shipped and trusted as part of Apple’s operating-system platform; Apple platform binaries may show no Team ID.

Frequently asked questions