peopled Is Eating Your Mac. Don’t Kill It Yet.

A burst of peopled activity after a macOS update can be ordinary database work. Days of sustained CPU, heat, battery drain, and instant respawns point to something less healthy.

By CoreGuard · Jul 11, 2026 · 12 min read

What is the peopled process on a Mac?

peopled is an Apple-supplied background daemon in /System/Library/PrivateFrameworks/People.framework/. It coordinates people and contact context used by macOS services; it is a normal system component, not an app you installed and not evidence of malware.

I inspected the shipping binary on macOS Tahoe 26.5.2. It links directly against Apple’s Contacts, CallHistory, Messages internals (IMCore), Screen Time, EventKit, and People frameworks. Its own symbols mention contact fetching, call-history fetching, people indexing, status sources, and contact-widget suggestions. That is a much better description than the usual internet answer—“something to do with people”—which is technically true in the least useful way possible.

The practical model is this: several macOS features need to know that a phone number, message participant, recent caller, widget suggestion, and contact card refer to the same person. peopled sits in that people-context layer. Nearby processes include contactsd, which—per its man page, contactsd(8)—manages the information in your contacts database and performs background maintenance tasks, and CallHistorySyncHelper, which works with the call-history store. Apple does not publicly document peopled or CallHistorySyncHelper; they are private system services.

Photos complicates the story. Names attached to people in Photos can connect to Contacts, but the visual analysis and face-detection work belongs primarily to the photoanalysisd and mediaanalysisd family. I would not casually claim that peopled scans every face itself.

That distinction matters. If Photos is processing a newly migrated library, read our photoanalysisd explainer. If the activity follows contacts, recent calls, or opening the Contacts widget, peopled and its immediate siblings are the more plausible cluster.

What happened after macOS Tahoe 26.4?

On March 28, 2026, an M4 MacBook Air owner opened Apple Community thread 256271160 after updating to macOS Tahoe 26.4. The user reported that peopled stayed around 70–80% CPU, the Mac became warm while mostly idle, and the battery drained faster than usual. The behavior had continued for two days despite restarting, resetting Spotlight indexing, restarting contactsd, and sending peopled a force-kill signal.

By July 11, 2026, the thread showed 47 “Me too” reactions and reports mentioning Tahoe 26.4, 26.4.1, and 26.5. The latest visible reply was dated June 26, 2026. Those are user reports about particular Macs, not an Apple engineering bulletin and not a prevalence study.

The details are more interesting than the reaction count. One Tahoe 26.4.1 user reported peopled around 70% CPU while CallHistorySyncHelper used about 28%, alongside repeated access-denied messages involving ~/Library/Application Support/CallHistoryDB. Other participants said opening or configuring a Contacts widget appeared to trigger the loop. Another associated the recurrence with a Google contacts account.

Then there are the counterexamples. One contributor reported peopled at 0.0% CPU on four M-series Macs running Tahoe 26.5. Different users also reported that the same workaround either helped or did nothing.

That is exactly why I refuse to call “Tahoe bug” from one row in Activity Monitor. The thread supports a narrower conclusion: a cluster of users saw persistent peopled activity after Tahoe updates, and several machines showed contact-widget, account-sync, or CallHistoryDB symptoms. It does not establish one universal root cause.

Normal post-update churn or a stuck loop?

macOS updates do not end when the progress bar disappears. Databases may migrate. Search indexes may be rebuilt. Contacts and cloud accounts reconcile local records with server state. Photos may revisit parts of its library. A daemon briefly taking real CPU after an update can be doing legitimate work.

Apple does not publish a useful countdown for peopled. There is no honest rule that says “three hours is normal, three hours and one minute is broken.” I look at the shape of the work instead.

Activity looks more like ordinary churn when:

• It began immediately after an update or a large account/library change.
• CPU arrives in bursts rather than holding one level indefinitely.
• The trend declines between observations.
• Energy use and temperature settle when the Mac has been idle.
• Companion processes such as contactsd and CallHistorySyncHelper also settle.
• A restart does not immediately reproduce the same pattern.

A stuck loop has a different shape:

• peopled remains near the top of Activity Monitor while the Mac is otherwise idle.
• The behavior persists across days rather than gradually declining.
• It returns immediately after a restart or after the process respawns.
• CallHistorySyncHelper or contactsd stays active alongside it.
• Console shows the same operation or error repeating rapidly.
• A specific trigger—opening contact-widget configuration, enabling an account, or touching call-history data—reliably starts it again.

The reported 70–80% figure is a symptom, not a verdict. A legitimate calculation and a failed retry can occupy similar amounts of CPU. The difference is whether useful work progresses.

This is the same diagnostic rule I use for mediaanalysisd: a loud process is not automatically a bad process. Watch whether it finishes.

How to observe peopled without changing anything

Start with Activity Monitor. Choose View → All Processes, open the CPU tab, search for peopled, and sort by % CPU. Apple says Activity Monitor can search for a process and expose parent-child relationships through All Processes, Hierarchically in its Activity Monitor process guide, and can show system and user CPU activity over time per its View CPU activity guide.

Do not take one screenshot and declare a case closed. Watch several samples:

• Does % CPU fall, return in bursts, or stay flat?
• Is the accumulated CPU Time still climbing rapidly?
• Are contactsd and CallHistorySyncHelper active at the same time?
• Does the spike occur only after opening Contacts, Phone-related data, or widget settings?
• Does it disappear when the Mac is idle and connected to power?

Then open the Energy tab. Apple describes Energy Impact as a relative measure of current consumption and, on Mac laptops, 12 hr Power as the average impact over the previous 12 hours or since startup in its Energy pane documentation. This view is useful because a CPU number without battery context is only half a complaint.

For a read-only Terminal snapshot:

ps -axo pid,ppid,%cpu,time,etime,command |
  egrep '[p]eopled|[c]ontactsd|CallHistorySyncHelper'

%CPU shows the current snapshot. TIME shows accumulated CPU time. ELAPSED shows how long the process has existed. Run the command again later and compare; the delta matters more than either single reading.

You can also inspect recent unified-log entries without changing the databases:

log show --last 10m --style compact \
  --predicate '(process == "peopled") OR
               (process == "contactsd") OR
               (process == "CallHistorySyncHelper")'

I am looking for repetition, not one scary line. Logs contain routine warnings and privacy redactions. A single “Operation not permitted” does not prove the Tahoe thread’s CallHistoryDB scenario is happening on your machine; hundreds of identical attempts in a tight loop are more useful evidence.

Before sharing logs, remove usernames, home-folder paths, account identifiers, phone numbers, and contact data. Debug output has an annoying habit of becoming a privacy leak five minutes after someone pastes it into a public forum.

Activity Monitor can also generate a process sample through the Info window. A sample is useful to Apple Support because it shows where the daemon spent its time instead of merely proving that it spent time somewhere.

Why force-quitting peopled rarely answers the question

The original Tahoe 26.4 reporter had already tried killall -9 peopled. The daemon came back and resumed using CPU. That result is unsurprising: macOS supervises system daemons and can relaunch them when another service needs them.

A force-kill may make the CPU number vanish for a moment. It does not tell you whether the cause was a database migration, contact-account reconciliation, a widget request, a permissions problem, or a retry loop. If the same input remains, the replacement process receives the same input.

There is also a reason I will not turn this article into a row of copy-pasteable sudo killall commands. Apple’s Activity Monitor guidance says Force Quit ends a process immediately; open files can lose data, and other apps or processes that depend on it can experience problems.

That warning is general, but it is especially relevant around Contacts and call-history databases. Repeatedly terminating a process while it is accessing a store is not a diagnostic method. It is a slot machine with your personal data behind the glass.

If peopled remains busy across days, collect the macOS build, process sample, Activity Monitor observations, and a short redacted log window. Check whether a newer Tahoe update is available, then give the evidence to Apple Support. Evidence is slower than process whack-a-mole. It is also how software defects become reproducible.

How peopled relates to contactsd and the Photos daemons

These names are easy to mash into one mythical “indexing” process. Keep the jobs separate:

• peopled belongs to Apple’s People framework and connects person-related context across contacts, communications, widgets, and indexes.
• contactsd, per its man page, contactsd(8), manages the information in your contacts database, provides functionality to apps using the Contacts API, and performs various background maintenance tasks.
• CallHistorySyncHelper works with the call-history database. In Apple Community thread 256271160, some users reported it consuming CPU beside peopled or appearing in the same repeating log sequence.
• photoanalysisd and mediaanalysisd perform background analysis of photo and video libraries. They may be active after an OS or Photos-library change, but their presence does not prove that a peopled loop is healthy.

They can overlap because macOS features overlap. A contact can appear in recent calls, Messages, a widget, Siri suggestions, and a named person in Photos. Shared data does not mean one daemon performs every stage.

When two or three members of the family spike together, record that fact. It is far more useful than killing whichever name happened to sort first.

What CoreGuard will—and will not—tell you

This exact problem is why I care about history. Activity Monitor is excellent while you are staring at it. Most people are not staring at it when the Mac first becomes warm in a closed bag or starts losing charge at an empty desk.

CoreGuard is a local-only macOS health monitor. In the free version, it shows live CPU, GPU, RAM, temperatures, and fan RPM; names the top app or process in plain English; keeps basic history of readings; and provides threshold alerts. If peopled is the current resource leader, you can see its name beside the physical result—the load, heat, and fan response—instead of treating those as unrelated mysteries.

Every danger warning remains free. CoreGuard does not charge you to learn that something is abnormal.

Pro is a one-time $29 purchase for the deeper tools and portable evidence. Relevant here, that includes detailed per-app energy, longer trend history, CSV/JSON sensor-log export, and Condition Report export in PDF/JSON. Pro can also quit runaway processes, but the presence of that button does not turn killing peopled into good advice. A power tool still requires judgment.

The distinction around history is deliberate: basic history and threshold alerts are free; longer trends and export are Pro. I have seen too many monitoring products blur that line in their own copy. I would rather state it once, accurately.

CoreGuard cannot look at 75% CPU and divine whether Apple shipped a regression, a Google contacts account is retrying, or a private database has the wrong attribute. It cannot promise that a process will settle by a particular time. It observes the pattern, names the process, and gives you enough evidence to stop guessing.

The app makes zero network connections—no account, cloud, telemetry, analytics, or crash reporting. It supports macOS 13 and later on Apple Silicon and Intel, and the direct .dmg is Developer-ID signed and notarized by Apple.

CoreGuard is still pre-launch. You can get notified for launch or see the Free and Pro split. Until then, Activity Monitor already gives you enough to answer the first question: is peopled finishing work, or repeating it?

Observe a peopled CPU spike without changing system data

1. Show every process: Open Activity Monitor, choose View → All Processes, select the CPU tab, and search for peopled.
2. Record the pattern: Note % CPU, CPU Time, the macOS version, and whether contactsd or CallHistorySyncHelper is active at the same time.
3. Check energy: Open Activity Monitor’s Energy tab and compare current Energy Impact with the laptop’s 12-hour view where available.
4. Read recent logs: Run the read-only log show command from the article and look for one message repeating rapidly; redact personal paths and identifiers before sharing it.
5. Take a process sample: Select peopled, open its Info window, and use Sample Process to capture where it is spending time.
6. Compare later: Repeat the observation after an idle period. A falling trend suggests progressing work; days of unchanged activity or repeated identical errors justify sending the evidence to Apple Support.

Frequently asked questions