searchpartyd Isn’t a Virus — It’s Find My Watching for Lost Devices

You opened Activity Monitor to find out why your Mac is warm, and a process called searchpartyd is sitting near the top, burning CPU while you weren’t doing anything. Here’s exactly what it is, why it spikes, the 30-second test that proves what’s driving it, and how to calm it down without weakening your Mac’s security.

By CoreGuard · Jul 7, 2026 · 14 min read

It’s a small jolt the first time you see it. The Mac is warm, the fan is up, you open Activity Monitor expecting to catch some app misbehaving — and the thing near the top of the CPU list is a process you’ve never heard of, with a slightly ominous name, running hard while you weren’t doing anything. searchpartyd. “Search party” sounds like something scanning your machine. It isn’t.

Here’s the whole picture: what searchpartyd actually does, the handful of reasons it runs your CPU up, a 30-second test that proves what’s driving it, and how to quiet it down — including the one “fix” that quietly weakens your Mac and that you should skip.

What is searchpartyd?

searchpartyd is the macOS daemon behind Find My — specifically the part Apple calls offline finding. That’s the genuinely clever feature that lets a lost device be located even when it has no internet and no GPS: it quietly broadcasts over Bluetooth, and any nearby iPhone, iPad, or Mac — strangers’ devices, anonymously — can pick up that signal and relay an encrypted location back to you. The entire “hundreds of millions of Apple devices help find your stuff” network runs on this, and searchpartyd is the piece of it living on your Mac.

The name is Apple’s internal one: the project was “Search Party.” The daemon does the cryptography and the server side — it generates and rotates the keys, encrypts and decrypts location reports, and talks to Apple’s servers. The actual radio work (advertising and scanning over Bluetooth Low Energy) is handled by a sibling daemon, bluetoothd, which is why the two often light up together. There’s also a per-user helper you’ll sometimes see, searchpartyuseragent — a companion agent that runs the searchparty work in the context of your logged-in user account, a split a multi-user Mac needs and an iPhone doesn’t. Its man page is terse to the point of comedy (“is a daemon… Users should not run it manually”), so treat that division of labor as the practical shape of it: same job, spread across processes.

One thing worth knowing, because it’s the reassuring part: the design is aggressively private. Per Apple’s Platform Security guide, a lost device broadcasts a public key that is replaced roughly every 15 minutes, so it can’t be tracked by a fixed identifier, and the private keys are “never sent to Apple” — they’re shared only among your own devices, end-to-end encrypted through iCloud Keychain. searchpartyd is the thing doing that math on your Mac. It’s not watching you; it’s the reason a thief can’t quietly watch your lost laptop either.

Why is searchpartyd using so much CPU?

Because it’s work that almost never stops. Offline finding means constantly advertising your rotating keys and listening to the Bluetooth Low Energy traffic around you, and macOS keeps doing it even in low-power sleep so your Mac stays findable. A machine that’s left awake for long stretches never gets a real idle window, so the daemon just… stays busy. On a healthy Mac that’s a low, steady hum in the background. The cases that send people to Activity Monitor are when it climbs and stays climbed. A few things push it there:

• A stuck iCloud or Find My state. This is the big one. When iCloud is wedged mid-sync, or a Find My record is in a bad state, searchpartyd can loop instead of settling. In one Apple Community thread the user noticed iCloud “appeared stuck updating” on the affected Mac — and signing out and back in cleared it.
• A noisy Bluetooth environment — lots of nearby AirTags, Find My accessories, and other BLE devices means more beacons to process.
• Wake-from-sleep churn. Because finding continues through sleep and power transitions, the daemon can re-spin its CPU each time the Mac wakes.
• A corrupted keychain or Find My record that makes it retry crypto or repeatedly reach for a device it can’t resolve — a stuck loop rather than steady work.

There’s one pattern worth calling out honestly, because it’s all over the forums: Intel Macs get hit far harder than Apple Silicon. Users repeatedly report searchpartyd pinning a full core on Intel iMacs and MacBooks while an Apple-Silicon Mac on the same iCloud account barely registers — in one Apple Community thread an Intel iMac on macOS Sequoia sat at a reported ~100% of a core while its Apple-Silicon sibling on the same account stayed around 30%. Nobody outside Apple has a documented explanation; it looks like a scheduling or efficiency difference in how the work is handled, not something “wrong” with either machine. If you’re on Intel and this process is your top complaint, you’re in a well-documented crowd.

If this shape — a system process pinning the CPU while the app you’d blame sits idle — feels familiar, it’s the same one behind a Gatekeeper CPU storm we pulled apart: the heat is real, it’s just billed to a background daemon, not the window in front of you.

Is searchpartyd a virus?

No. The real searchpartyd is a legitimate Apple system daemon that ships inside macOS and runs from a protected system path. It’s not malware, it’s not a “PUP,” and it’s not something you installed by accident. The unsettling name is doing all the work here — “search party” sounds invasive, but the thing being searched for is a lost device, not your data.

The honest caveat — and the reason it’s a fair question — is that any file can be given a familiar name, and malware sometimes hides by borrowing the name of a trusted process. So the genuine-article test isn’t the name; it’s the path and the signature. The real one lives at /usr/libexec/searchpartyd and is code-signed by Apple. One command settles it — codesign -d --requirements - prints the signing requirement, and a genuine Apple binary ends in anchor apple:

The 30-second test: turn Bluetooth off

Before you try any “fix,” do this — it’s the single most useful thing in this whole article. Open Activity Monitor, watch searchpartyd, and turn Bluetooth off for a moment. In case after case, its CPU drops to near zero almost immediately. That tells you something concrete: the load really is Bluetooth work — offline finding — and not some runaway bug or malware pretending to be a system process. It’s the difference between a diagnosis and a guess.

Two honest caveats. First, leaving Bluetooth off is a workaround, not a fix — you lose AirDrop, Continuity, and your wireless mouse, keyboard, and headphones, and your Mac stops participating in Find My. Turn it back on once you’ve proven the point. Second, this confirms what is busy, not why it’s stuck — for that, keep reading.

Can I quit or disable searchpartyd?

You can quit it, and it’s safe to do so — but understand what happens. searchpartyd is managed by launchd, the macOS service manager, so the instant you quit it (Activity Monitor → select → Quit, or sudo killall searchpartyd), launchd relaunches it fresh. That’s not a bug; it’s how system daemons work. Quitting it once can clear a temporarily stuck loop — a fair number of people report the spike drops after a kill or two — but if the underlying trigger (that wedged iCloud state, say) is still there, it’ll climb back.

You cannot truly delete or permanently disable it. The binary lives on the sealed, read-only system volume, so it always comes back after a reboot. The only switch that actually stops its work is turning off Find My Mac — and that’s where you need to stop and think, because of the next section.

Why not to just turn off Find My

It’s the obvious move — searchpartyd is Find My, so turn off Find My and it goes quiet — and it’s a bad trade. Turning off Find My does two things beyond silencing the daemon: it disables offline finding (so a lost Mac can’t be located by the network), and it removes Activation Lock. Per Apple, “when you turn off Find My on your Mac, Activation Lock is automatically removed” — and Activation Lock is the feature that ties your Mac to your Apple Account so a thief can’t erase and reuse it without your password.

So the honest framing: turning off Find My to quiet a background process is trading real theft protection for a cooler-running CPU. For a machine that lives on your desk and never leaves, you might decide that’s acceptable — but it’s a security decision, not a “fix,” and it should be a deliberate last resort, not the first thing you reach for.

How to calm searchpartyd down (safely)

In rough order of “least disruptive, most likely to help”:

1. Reboot. Boring, but it clears a surprising share of transient high-CPU states, searchpartyd included.
2. Quit it once. In Activity Monitor, select searchpartyd and quit it; launchd relaunches it clean. If the spike was a stuck loop, this can end it.
3. Toggle Bluetooth off, then on. Beyond being the diagnostic test above, cycling Bluetooth sometimes resets a wedged offline-finding state.
4. Sign out of iCloud and back in. This is the fix that stuck for the worst reported cases, because it re-syncs a jammed Find My/keychain state. One important warning first: if your Desktop & Documents folders sync to iCloud Drive (a default-on setting), signing out can remove the local copies of those files. When macOS prompts, choose “Keep a Copy,” and make sure you have a backup before you start. Don’t rush the dialog.
5. Prune your Find My inventory. Remove dead or unused devices and old AirTags from Find My so there’s simply less for it to track.
6. Let the Mac actually sleep. If you keep it awake around the clock, the daemon never gets an idle window. Enabling display and system sleep gives it room to settle.
7. Keep macOS updated. Some searchpartyd and Bluetooth CPU regressions have been addressed in point releases. Not a guarantee, but the right move for a known bug.

And a short list of things not to do, because they’re all over the search results and none of them earn their risk: don’t run a “cleaner” or “antivirus” app to fix it (a cleaner can’t touch a system daemon’s CPU behavior); don’t reinstall macOS or wipe the drive as an early step (it just resets the same iCloud state a sign-out resets for free); and don’t bother with an NVRAM/SMC reset for this — users tried it in the long Intel threads and it didn’t move the needle.

When is searchpartyd actually a problem?

Reach for the escalation path when all of these hold at once:

• It’s been pinning a full core for days or weeks, not minutes.
• The Bluetooth-off test confirms it’s really searchpartyd (CPU drops to zero without it), so you’re not chasing a mislabeled process.
• Nothing above helped — not a reboot, not a sign-out/in, not updates.

That combination — especially on an Intel Mac — is where a normal background hum has crossed into a likely OS bug. Several of the longest threads ended with no user-level cure and a strong suspicion of exactly that. The productive move at that point isn’t more force-quitting; it’s keeping macOS current and filing a report with Apple through Feedback Assistant so the pattern is on their radar. What you should not do to “win” is disable Find My and lose Activation Lock over it.

What CoreGuard shows during a searchpartyd spike

This is the part where I’m building CoreGuard for exactly this moment, so let me be concrete — and honest about what it does and doesn’t do.

The hard part of a night like this usually isn’t fixing anything — it’s knowing whether the scary process is a normal background job or a real problem, and being able to watch instead of guess. That’s what CoreGuard is for here. It names the actual top process in plain English — “searchpartyd — Find My offline finding,” not a cryptic string — so you know instantly it isn’t malware. It shows live temperatures, fan RPM, and CPU/load, and it keeps a history, so you can see whether searchpartyd is a brief spike that settles or a flat line that’s been pinned for days — the exact distinction that tells you “wait” from “investigate.” The process naming, the live readings, and every danger warning are free, forever; per-app energy detail over time is part of Pro.

The honest limits, in plain text: CoreGuard does not stop, throttle, speed up, or “fix” searchpartyd, and it is not an antivirus. It wouldn’t make sense to — this is Apple’s own daemon doing legitimate work, and the right answer is usually to leave Find My on and let it run. What CoreGuard changes is the part that sends people down a rabbit hole of force-quitting system processes at midnight: it turns “some unknown thing named ‘search party’ is hammering my Mac” into “that’s Find My, here’s the trend, here’s what’s normal.” It’s also local-only — zero network connections, no account, no telemetry — which you can verify yourself with lsof -i -nP | grep CoreGuard and watch nothing happen.

CoreGuard isn’t out yet — the download and checkout go live shortly. Free covers the live readings, the “what’s eating your Mac” process naming, the history, and every danger warning, forever; Pro is a one-time $29 (Family $49), perpetual, not a subscription, with a 30-day money-back guarantee. So the honest ask: get notified and grab it free at launch, or see what Pro adds. Either way — next time a process you don’t recognize runs your Mac warm, check the name, run the Bluetooth test, and look at the trend before you reach for anything drastic.

Frequently asked questions