peopled lässt die CPU Ihres Mac unter macOS Tahoe volllaufen? Meist ist das Kontakte-Widget schuld

Ihr Mac wird warm, obwohl er nichts tut. Die Akkuschätzung hat sich halbiert. Sie öffnen die Aktivitätsanzeige, sortieren nach CPU, und ganz oben steht ein Prozess, von dem Sie noch nie gehört haben — peopled — der bei 70 oder 80 Prozent verharrt. Oder es ist contactsd. Oder, bei den am schlimmsten betroffenen Geräten, accountsd bei 180 % mit contactsd und itunescloudd dahinter. Beenden bringt nichts, weil Sie die Prozesse gar nicht beenden können. Ein Neustart hilft für eine Stunde.

Das passiert Mac-Nutzern seit macOS Tahoe 26.4 im März, es passiert weiterhin unter 26.5 und 26.6, Apple hat es nicht bestätigt, und die zuverlässigste Lösung steht in keinem der „Starten Sie Ihren Mac neu / Setzen Sie den NVRAM zurück"-Artikel, die für die Suche ranken. Sie besteht darin, ein Widget zu entfernen.

Dieser Leitfaden erklärt, was peopled ist (wir haben hineingeschaut), warum ein Widget den Prozess in eine Schleife treibt, warum ein Quarantäne-Flag auf einem Ordner, von dessen Existenz Sie nichts wussten, der andere Auslöser ist, und in welcher genauen Reihenfolge Sie die Lösungen ausprobieren sollten.

Wichtigste Erkenntnisse

• peopled ist der Daemon hinter dem Kontakte-Widget. Seine eigene Binärdatei enthält Klassen namens WidgetSuggester, WidgetConfigurationReader und CallHistoryFetcher, und sein Sandbox-Profil gewährt ihm Zugriff auf Ihre Anrufverlaufsdatenbank. Diese Kombination ist die Schleife.
• Lösung 1: Entfernen Sie jedes Kontakte-Widget — vom Schreibtisch, aus der Mitteilungszentrale und aus dem Kontrollzentrum — und starten Sie dann neu. Das hat die Mehrheit der über 54 bestätigten Meldungen in Apples Community-Forum gelöst.
• Lösung 2: Entfernen Sie das Quarantäne-Flag auf ~/Library/Application Support/CallHistoryDB und beenden Sie peopled. Das ist die Lösung, wenn es kein Widget zu entfernen gibt; sie erfordert Festplattenvollzugriff für Terminal.
• Lösung 3: Deaktivieren Sie iCloud-Kontakte und aktivieren Sie sie danach wieder. Funktioniert bei manchen, nicht bei allen, und kostet Sie die Synchronisierung, solange sie deaktiviert ist.
• CPU-Spitzen von contactsd bei einem Exchange- oder Google-Konto sind ein anderer, älterer Fehler mit demselben Symptom, aber einer anderen Lösung — das Konto entfernen oder einen Client eines Drittanbieters verwenden.
• Apple hat keine Lösung dokumentiert. In den Versionshinweisen zu 26.4.1, 26.5, 26.6 oder 26.6.x wird das Problem nirgends erwähnt, und Meldungen zu 26.5 und später halten weiter an.

Welcher Prozess genau

In diesen Meldungen tauchen drei Daemons auf, und sie sind nicht austauschbar. Sortieren Sie die Aktivitätsanzeige nach % CPU und notieren Sie, welchen Sie vor sich haben.

Prozess	Wozu er gehört	Typische Meldung	Wahrscheinlichste Ursache
peopled	People-Framework — Widget-Vorschläge, Familienfreigabe, Bildschirmzeit, Status	Anhaltend 70–80 % seit 26.4	Kontakte-Widget + nicht lesbare CallHistoryDB
contactsd	Contacts-Framework — die Adressbuchdatenbank und Synchronisierung	Spitzen bis 80 % alle 60–90 s, oder anhaltend	Synchronisierungsschleife bei iCloud/Exchange/Google-Kontakten
accountsd	Accounts-Framework — jedes angemeldete Konto	180 % zusammen mit contactsd und itunescloudd	Authentifizierungsschleife des Kontos; Abmelden hilft oft nicht

Wenn es peopled ist, beginnen Sie mit dem Abschnitt zum Widget. Wenn es allein contactsd ist, springen Sie zum Abschnitt über die Synchronisierungskonten. Wenn es alle drei sind, mit accountsd obenauf, befinden Sie sich in der am wenigsten verstandenen Variante, und der entsprechende Abschnitt ist ehrlich darüber, wie wenig bekannt ist.

Was peopled tatsächlich tut

Der Name legt Kontakte nahe, und die Anleitungen, die ihn überhaupt erwähnen, beschreiben ihn als „verwaltet Kontaktdaten". Das ist ungefähr richtig und im Detail falsch, und dieser Unterschied ist der Grund, warum die Lösung ein Widget betrifft und keine Reparatur des Adressbuchs.

Wir haben den Daemon auf einem Mac unter 26.5.2 untersucht. Er befindet sich unter /System/Library/PrivateFrameworks/People.framework/peopled, und sein launchd-Job (/System/Library/LaunchAgents/com.apple.peopled.plist) verrät, was ihn weckt. Er wird nicht beim Anmelden geladen — RunAtLoad ist auf false gesetzt. Er wird durch Ereignisse gestartet:

• Biome-Streams für missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest und childState
• Zwei Systembenachrichtigungen: __ABDataBaseChangedByOtherProcessNotification (das Adressbuch hat sich geändert) und _CalDatabaseChangedNotification (der Kalender hat sich geändert)

Jeder verpasste Anruf, jede Nachricht, jede Kontaktänderung und jede Kalenderänderung weckt also peopled. Und was tut er, wenn er geweckt wird? Die Strings in seiner Binärdatei beantworten das unmittelbar. Unter den Swift-Klassennamen:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

und unter seinen Log-Nachrichtenvorlagen:

Event triggered widget refresh: %{private}s, %s
Last widget suggestion date is older 24 hours, suggest widgets
Last widget suggestion date is within 24 hours, do not suggest widgets
error reading widgets configurations: %s
Failed to suggest widgets with error: %s

Er bindet das Contacts-Framework, das CallHistory-Framework und zwei Biome-Frameworks ein. Sein Zweck, soweit ihn der eigene Code beschreibt, besteht darin, zu entscheiden, welche Personen im Kontakte-Widget und in personenbezogenen Vorschlägen angezeigt werden, wobei Ihre letzten Anrufe und Nachrichten als Signal dienen.

Das erklärt, warum dieses Fehlerbild Sinn ergibt: ein Daemon, der durch jeden Anruf und jede Nachricht geweckt wird, dessen Aufgabe es ist, ein Widget zu aktualisieren, und der dafür den Anrufverlauf lesen muss.

Warum er in der Schleife hängt

Legen Sie die Fragmente aus dem Community-Thread neben das, was die Binärdatei aussagt.

peopled läuft innerhalb einer Sandbox. Sein Profil unter /System/Library/Sandbox/Profiles/com.apple.peopled.sb beginnt mit (deny default) und öffnet dann gezielt einzelne Türen. Zwei davon:

(home-subpath "/Library/CallHistoryDB/")
(home-subpath "/Library/Logs/CallHistory")

Er darf also ~/Library/Application Support/CallHistoryDB/ lesen, wo macOS die Datenbank der über Ihr iPhone via Continuity geführten und empfangenen Anrufe speichert. Dieser Ordner ist außerdem durch TCC geschützt — auf unserem Mac liefert ls darauf aus Terminal Operation not permitted, solange Terminal keinen Festplattenvollzugriff hat —, weshalb die unten genannten Lösungen diese Berechtigung benötigen.

Nun zu den Meldungen. Am 21. April zitierte ein Nutzer in Apples Community-Thread die Kernel-Meldung, die er in der Konsole fand, während peopled sich drehte:

Sandbox: peopled … deny(1) file-read-data ~/Library/Application Support/CallHistoryDB

Und am 20. Mai zitierte ein anderer:

failed to open /Users/[user]/Library/Application Support/CallHistoryDB: 1 (Operation not permitted)

Die Deutung, die zu all dem passt: Ein Kontakte-Widget ist installiert, also wird peopled aufgefordert, es zu aktualisieren; die Aktualisierung bedeutet, den Anrufverlauf abzurufen; der Abruf wird verweigert — weil der Ordner ein com.apple.quarantine-Attribut erhalten hat, oder aus einem anderen Berechtigungsgrund, den die Meldungen nicht eingegrenzt haben —, die Aktualisierung schlägt fehl, und das nächste Ereignis (oder der erneute Versuch) löst sie wieder aus. Ein Daemon, der nach einem verpassten Anruf eigentlich nur Millisekunden laufen sollte, läuft stattdessen ununterbrochen.

Wir möchten präzise sagen, was hier gesichert ist und was nicht. Die Klassennamen, die Sandbox-Regeln und die Log-Meldungen sind direkt beobachtbar; wir haben sie gelesen. Dass die Schleife „Widget-Aktualisierung, verweigerter Lesezugriff, erneuter Versuch" lautet, ist eine Schlussfolgerung, die zu jeder uns bekannten Meldung und zu beiden funktionierenden Lösungen passt. Apple hat den Mechanismus nicht bestätigt, und es könnte einen zweiten Auslöser geben — ein Nutzer berichtet, dass die Schleife nach dem Neuordnen des Kontrollzentrums begann, obwohl überhaupt kein Kontakte-Widget vorhanden war.

Erst bestätigen, dann etwas ändern

Zwei Minuten Hinsehen ersparen eine Stunde Raten, und das Muster der CPU-Nutzung verrät Ihnen, zu welcher Lösung Sie greifen sollten.

Beobachten Sie das Muster. Wählen Sie den Prozess in der Aktivitätsanzeige aus und sehen Sie sich den CPU-Verlauf in der Fußzeile des Fensters an, oder aus Terminal:

top -stats pid,command,cpu,time -o cpu -n 5

Ein peopled, das konstant bei 70–80 % verharrt, ist die Widget-Schleife. Ein contactsd, das ausschlägt, auf null fällt und eine Minute später erneut ausschlägt, ist die Synchronisierungsschleife. Anhaltende CPU-Last auf allen drei Daemons gleichzeitig ist die Konten-Variante.

Prüfen Sie, wie lange der Prozess schon läuft. peopled lebt normalerweise nur Sekunden. Auf unserem (gesunden) Mac ist er seit 41 Tagen bei 0,0 % CPU resident — resident, aber untätig, ist in Ordnung. Wonach Sie suchen, ist resident und beschäftigt:

ps -axo pid,etime,pcpu,comm | grep -E "peopled|contactsd|accountsd"

Suchen Sie nach der Verweigerung. Das ist der entscheidende Test. Öffnen Sie ein zweites Terminal-Fenster und lassen Sie sich das Log des Daemons live anzeigen, während er sich dreht:

log stream --predicate 'process == "peopled"' --info

und durchsuchen Sie im ersten Fenster die letzten paar Minuten nach der Sandbox-Zeile, die die Community-Meldungen zitieren:

log show --last 10m --predicate 'eventMessage CONTAINS "Sandbox: peopled"'

Wenn Sie deny(1) file-read-data gegen CallHistoryDB sehen, haben Sie die CallHistoryDB-Variante, und Lösung 2 ist die, die funktionieren wird. Wenn Sie Event triggered widget refresh wiederholt ohne Verweigerung sehen, beginnen Sie mit Lösung 1. Wenn das Log ruhig ist und die CPU-Last hoch, liegt die Schleife in Code, der auf der Standardebene nicht protokolliert wird; probieren Sie die Lösungen trotzdem der Reihe nach aus.

Beobachten Sie das Dateisystem, wenn Sie Gewissheit wollen. fs_usage zeigt jede Dateioperation, die ein Prozess versucht, einschließlich der fehlgeschlagenen:

sudo fs_usage -w -f filesys peopled

Ein Bildschirm voller Zugriffsversuche auf CallHistoryDB, die Fehler zurückgeben, ist die Schleife — live sichtbar.

Lösung 1: Das Kontakte-Widget entfernen

Das ist die Lösung mit den meisten Bestätigungen, und sie sollten Sie zuerst ausprobieren, weil sie reversibel ist und kein Terminal erfordert.

Der Haken ist, dass es auf einem Tahoe-Mac drei Orte gibt, an denen ein Widget existieren kann, und es muss von allen dreien verschwinden.

Schreibtisch

Klicken Sie bei gedrückter Ctrl-Taste auf den Schreibtischhintergrund und wählen Sie Widgets bearbeiten. Jedes Kontakte-Widget auf dem Schreibtisch zeigt beim Bearbeiten eine Entfernen-Schaltfläche (das Minus in der Ecke); klicken Sie darauf. Alternativ klicken Sie bei gedrückter Ctrl-Taste auf das Widget selbst und wählen Widget entfernen. Klicken Sie auf Fertig.

Mitteilungszentrale

Klicken Sie in der Menüleiste auf Datum und Uhrzeit, um die Mitteilungszentrale zu öffnen, scrollen Sie nach unten und klicken Sie auf Widgets bearbeiten. Entfernen Sie jedes dortige Kontakte-Widget auf dieselbe Weise — Ctrl-Klick und Widget entfernen, oder Option-Klick auf die Entfernen-Schaltfläche.

Kontrollzentrum

Diesen übersehen die meisten, weil Tahoe Widgets ins Kontrollzentrum verschoben hat und die Anpassung nicht in den Systemeinstellungen liegt. Klicken Sie auf das Symbol des Kontrollzentrums in der Menüleiste, wählen Sie Steuerelemente bearbeiten und ziehen Sie jedes Kontakte-Element aus dem Kontrollzentrum heraus. Klicken Sie auf Fertig.

Dann starten Sie neu — nicht nur abmelden. Mehrere bestätigte Lösungen im Thread merken an, dass die CPU-Last erst nach einem vollständigen Neustart zurückging.

Eine weitere Warnung aus demselben Thread, gemeldet am 31. Juli: Bei einigen Nutzern kehrte die Schleife zurück, nachdem sie die Widget-Galerie erneut geöffnet hatten — selbst ohne das Kontakte-Widget hinzuzufügen. Wenn Sie dieses Problem hatten, meiden Sie den Widget-Editor, bis Apple den Daemon repariert.

Lösung 2: Das Quarantäne-Flag auf CallHistoryDB entfernen

Für Macs ohne jegliches Kontakte-Widget, oder bei denen das Entfernen nicht half, ist dies die Lösung, zu der die technisch detaillierteste Meldung im Thread am 20. Mai gelangte und die mindestens zwei weitere Nutzer bestätigten („peopled-Prozess liegt jetzt bei 0 % CPU-Verbrauch", schrieb einer am 26. Juni).

Schritt 1: Terminal Festplattenvollzugriff gewähren

Systemeinstellungen > Datenschutz & Sicherheit > Festplattenvollzugriff, Terminal hinzufügen und aktivieren. Ohne das schlägt jeder der folgenden Befehle mit „Operation not permitted" fehl — was zufällig genau der Fehler ist, auf den auch peopled stößt. Starten Sie Terminal nach der Freigabe neu.

Schritt 2: Den Ordner betrachten

ls -lan@ "$HOME/Library/Application Support/CallHistoryDB"

Die Option @ zeigt erweiterte Attribute. Wonach Sie suchen, ist com.apple.quarantine auf dem Ordner oder auf den darin enthaltenen CallHistory.storedata-Dateien. Quarantäne ist das Flag, das macOS heruntergeladenen Dateien anhängt; auf einer Systemdatenbank hat es nichts verloren, und wie es dorthin gelangt, ist nicht bekannt — eine Wiederherstellung aus einem Backup und eine Migration von einem anderen Mac sind die beiden plausiblen Wege.

Schritt 3: Es entfernen

xattr -dr com.apple.quarantine "$HOME/Library/Application Support/CallHistoryDB"

-d löscht das Attribut, -r durchläuft den Ordner rekursiv.

Schritt 4: Die Daemons neu starten

sudo killall -9 peopled CallHistorySyncHelper

Beide werden bei Bedarf neu gestartet. Beobachten Sie die Aktivitätsanzeige einige Minuten lang.

Falls das Flag zurückkehrt

Ein Nutzer im Thread berichtete am 17. Juli, dass die Lösung funktionierte, das Quarantäne-Flag aber über Nacht „wieder auftauchte". Wenn Ihnen das passiert, quarantänisiert etwas den Ordner erneut, und die Kandidaten sind ein Backup- oder Synchronisierungstool, das ihn als neue Daten behandelt. Prüfen Sie, was nachts läuft. Alternativ, und deutlich robuster, bestand der Ansatz eines anderen Nutzers darin, die Datenbank zu löschen und macOS sie neu erstellen zu lassen:

rm -rf ~/Library/Application\ Support/CallHistoryDB

Sie verlieren die auf dem Mac gespeicherte Kopie Ihres Anrufverlaufs. Sie füllt sich über Continuity vom iPhone aus wieder auf. Das ist ein größerer Hammer als das Entfernen eines Attributs, und wir würden zuerst das Attribut versuchen.

Lösung 3: iCloud-Kontakte umschalten

Systemeinstellungen > [Ihr Name] > iCloud > In iCloud sichern > Kontakte, ausschalten. Eine Minute warten, die CPU beobachten. Sinkt sie, schalten Sie sie wieder ein und beobachten, ob sie unten bleibt.

Das funktioniert bei einem Teil der Nutzer und ist der Standardrat in den älteren Vorläufer-Threads, die Jahre zurückreichen. Es hat auch einen Fehlerfall, auf den ein Nutzer am 11. Mai stieß: Der Schalter ließ sich überhaupt nicht ausschalten. Falls Ihnen das passiert, melden Sie sich vollständig von iCloud ab (behalten Sie bei Nachfrage eine Kopie der Daten), starten Sie neu und melden Sie sich wieder an. Beachten Sie, dass der Berichterstatter auf V2EX mit der accountsd-Variante genau das versuchte und die CPU-Last nach dem Anmelden sofort zurückkehrte.

Wenn es contactsd ist und Sie ein Exchange- oder Google-Konto haben

Dieser Fall existiert schon vor Tahoe und hat einen saubereren Mechanismus.

contactsd ist der Daemon des Contacts-Frameworks: Er verwaltet die Adressbuchdatenbank und gleicht sie mit jedem Konto ab, das Kontakte synchronisiert. Er erledigt außerdem planmäßig Aufräumarbeiten — sein launchd-Job registriert eine tägliche validate-cache-Aufgabe, die nur bei externer Stromversorgung ausgeführt wird, während Sie inaktiv sind, sowie eine wiederkehrende accounts.cleanup-Aktivität. Gelegentliche, kurze CPU-Last durch contactsd ist normal.

Nicht normal ist eine Spitze etwa jede Minute. Ein Entwickler dokumentierte genau das im Dezember 2025 in den Apple Developer Forums: Auf einem M1 Max unter Tahoe 26.1 trieb ein Office-365-Konto mit aktivierten Kontakten AddressBookManager auf 81 % und contactsd auf 22–59 % in einem sich alle 60–90 Sekunden wiederholenden Muster — selbst mit auf dem Server geleertem Exchange-Kontakteordner, und reproduzierbar bei einer sauberen Neuinstallation. Dasselbe Konto und dieselben Daten zeigten dieses Verhalten weder auf einem M4-Mac noch unter iOS. Niemand von Apple antwortete.

Sein Workaround ist der, der funktioniert: das Exchange-Konto aus Systemeinstellungen > Internet-Accounts entfernen und, falls benötigt, Outlook verwenden, das nicht über das Contacts-Framework läuft. Eine Meldung im Community-Forum vom Februar mit contactsd auf einem MacBook Pro (2024) unter 26.3 erhielt den entsprechenden Rat — die Kontaktsynchronisierung von Exchange und Google stoppen und testen — und wenn sowohl iCloud als auch ein Google-Konto Kontakte synchronisieren, zuerst Google ausschalten.

Die accountsd-Variante

Die schwerwiegendsten Meldungen — accountsd bei 180 % mit contactsd und itunescloudd im Schlepptau, auf einem MacBook Air M5 unter 26.5.2, im Juli auf V2EX beschrieben — haben keine bestätigte Lösung. Der Berichterstatter merkte an, dass es jeden Morgen zur selben Uhrzeit begann, was eher auf eine geplante Aufgabe als auf ein Widget-Ereignis hindeutet. Ab- und wieder anmelden half nicht.

Was wir ergänzen können: accountsd ist der Daemon des Accounts-Frameworks und wird immer dann aufgerufen, wenn irgendetwas eine Anmeldeinformation für ein angemeldetes Konto benötigt, und itunescloudd ist der Bibliotheks-Daemon von iTunes Cloud (Apple Music / Store). Alle drei gleichzeitig bedeuten, dass irgendetwas wiederholt Kontoanmeldedaten anfordert und dabei scheitert. Wenn Sie diese Variante haben, lohnt es sich trotzdem, die obigen Lösungen der Reihe nach auszuprobieren, und wenn keine davon hilft, sollten Sie prüfen, ob ein einzelnes Konto — ein alter Google- oder Exchange-Login, ein abgelaufenes app-spezifisches Passwort — die Authentifizierung unter Systemeinstellungen > Internet-Accounts scheitern lässt. Entfernen Sie alles, was ein Warnsymbol zeigt.

Warum Tahoe, und warum ein Widget

Widgets gibt es auf dem Mac schon seit Jahren, daher ist die Frage berechtigt, warum das erst mit 26.4 begann. Zwei Dinge änderten sich gleichzeitig.

Das Erste ist, wo Widgets leben. Tahoe hat Widgets zusätzlich zum Schreibtisch und zur Mitteilungszentrale ins Kontrollzentrum gebracht, und ein Kontakte-Widget im Kontrollzentrum wird in einem anderen Rhythmus aktualisiert als eines auf dem Schreibtisch — die eigenen Log-Vorlagen des Daemons unterscheiden einen täglichen „Widgets vorschlagen"-Durchlauf („Last widget suggestion date is older 24 hours") von ereignisgesteuerten Aktualisierungen („Event triggered widget refresh"). Mehr Oberflächen, mehr Aktualisierungsanfragen, mehr Gelegenheiten für einen fehlgeschlagenen erneuten Versuch.

Das Zweite ist, dass die Fehlerbehandlung des Daemons offenbar erneut versucht, statt zurückzuweichen. Das ist unsere Schlussfolgerung aus dem Verhalten, nicht etwas, das wir in der Binärdatei ablesen können, und es ist der eigentliche Fehler: Ein verweigerter Lesezugriff sollte einmal protokolliert und die Aktualisierung bis zum nächsten echten Ereignis aufgegeben werden. Stattdessen wird sie erneut versucht, und die Ereignisse kommen weiter.

Keines von beidem können Sie ändern. Was Sie ändern können, ist, ob das Widget existiert und ob der Lesezugriff verweigert wird — genau das bewirken die drei Lösungen.

Nachdem es behoben ist

Ein paar Dinge halten es dauerhaft behoben.

Lassen Sie den Festplattenvollzugriff von Terminal bestehen, wenn Sie Lösung 2 verwendet haben, oder widerrufen Sie ihn bewusst — beides ist in Ordnung, aber wissen Sie, wofür Sie sich entschieden haben, denn Terminal mit Festplattenvollzugriff ist eine weitreichende Berechtigung.

Meiden Sie eine Weile die Widget-Galerie. Die Meldung vom 31. Juli im Thread ist eindeutig, dass bereits das Öffnen — nicht das Hinzufügen — die Schleife neu startete. Wenn Sie andere Widgets hinzufügen möchten, tun Sie es und prüfen Sie danach die Aktivitätsanzeige.

Prüfen Sie nach dem nächsten macOS-Update erneut. Punkt-Updates haben bei manchen Nutzern die Standardelemente des Kontrollzentrums wieder hinzugefügt, und ein still zurückkehrendes Kontakte-Widget ist der wahrscheinlichste Grund, warum das Problem erneut auftritt.

Melden Sie das Problem. Feedback Assistant, Kategorie macOS, hängen Sie eine sysdiagnose an, die bei hoher CPU-Last aufgenommen wurde (sudo sysdiagnose aus Terminal, oder Umschalt-Ctrl-Option-Befehl-Punkt), und fügen Sie die Sandbox-Verweigerungszeile ein. Fünf Monate an Forum-Threads haben daran nichts bewegt; ein paar hundert Feedback-Meldungen mit derselben Log-Zeile könnten es.

Ist es schon behoben?

Nein, soweit erkennbar. Wir haben Apples Versionshinweise zu Tahoe geprüft: 26.4.1 „enthält Fehlerbehebungen", 26.5 „enthält Verbesserungen, Fehlerbehebungen und Sicherheitsupdates", 26.6 optimiert den Spotlight-Index, und 26.6.1 sowie 26.6.2 sind Sicherheitsupdates. Keine erwähnt Kontakte, Widgets oder CPU. Im Community-Thread halten die Meldungen unter 26.5 an („The issue still exists in Tahoe 26.5. Apple needs to fix this asap", am 15. Mai) und reichen bis in den Juli. Für 26.6.2, das am 17. August erschien, haben wir bislang weder in die eine noch in die andere Richtung eine Meldung gesehen.

Wenn Sie die macOS-27-Beta nutzen und dies gesehen haben oder nicht, verfolgen wir das in unserer Übersicht der bekannten Beta-Probleme.

Was Sie sich sparen können

NVRAM oder SMC zurücksetzen. Keines von beidem hat etwas mit den Dateiberechtigungen eines Daemons im User-Space zu tun. Überspringen.

tccutil reset All. Ein Nutzer probierte es aus; es half nicht, und es entzieht jeder App auf dem Mac sämtliche Datenschutzberechtigungen, die Sie dann einen Nachmittag lang wieder neu vergeben. Es gibt keinen Grund zur Annahme, dass TCC die fehlerhafte Ebene ist — die Verweigerung in den Logs stammt von der Sandbox, nicht von TCC.

Sicherer Modus. Das Starten in den sicheren Modus und zurück leert einige Caches und verschaffte einigen Nutzern vorübergehend Erleichterung. Es ist ein Neustart mit Extraschritten und behebt nicht die Ursache.

peopled mit launchctl deaktivieren. Sie können den Agenten per launchctl disable deaktivieren, und er wird keine CPU mehr verbrauchen, weil er nicht mehr läuft. Er stoppt dann aber auch das Kontakte-Widget, Personenvorschläge, die „Kaufanfrage"-Mechanik der Bildschirmzeit und alles andere, was davon abhängt, und auf einem durch System Integrity Protection geschützten Mac übersteht die Änderung möglicherweise kein Update. Nicht empfohlen, außer als letztes diagnostisches Mittel.

Häufige Probleme beheben

Die Aktivitätsanzeige zeigt zwanzig Kopien von contactsd

Das haben wir selbst beim Schreiben beobachtet: ein Schwall von zwanzig contactsd-Prozessen mit fortlaufenden PIDs, alle Kinder von launchd, alle bei 0 % CPU, innerhalb einer Minute wieder verschwunden. Das ist launchd, das bei Bedarf pro Client eine eigene Instanz erzeugt, und das ist nicht der Fehler. Der Fehler ist ein einzelner Prozess mit hoher CPU-Last, der bestehen bleibt.

Das Kontakte-Widget ist weg, aber peopled liegt weiterhin bei 80 %

Prüfen Sie alle drei Orte — Schreibtisch, Mitteilungszentrale, Kontrollzentrum — und wechseln Sie dann zu Lösung 2. Wenn Sie nie ein Kontakte-Widget hatten, gehen Sie direkt zu Lösung 2.

xattr meldet „No such xattr: com.apple.quarantine"

Der Ordner ist nicht unter Quarantäne, also ist das nicht Ihr Auslöser. Probieren Sie Lösung 3, und prüfen Sie, ob ein Exchange- oder Google-Konto Kontakte synchronisiert.

ls auf CallHistoryDB meldet „Operation not permitted" selbst mit sudo

sudo umgeht TCC nicht. Terminal selbst braucht Festplattenvollzugriff, gewährt in den Systemeinstellungen, und muss anschließend neu gestartet werden.

Es kam nach einem macOS-Update zurück

Updates können das Widget dem Standardlayout des Kontrollzentrums wieder hinzufügen. Prüfen Sie erneut die drei Orte.

FAQ

Ist peopled Malware?

Nein. Es ist ein von Apple signierter Daemon unter /System/Library/PrivateFrameworks/People.framework/peopled auf dem versiegelten Systemvolume. Ein Prozess mit diesem Namen, der von anderswo läuft, wäre eine Untersuchung wert; dieser hier gehört Apple.

Kann ich ihn einfach beenden?

sudo killall peopled stoppt ihn, bis ihn das nächste Ereignis weckt — auf einem aktiv genutzten Mac sind das Sekunden. Nützlich ist das als Diagnose — bleibt die CPU-Last nach dem Beenden niedrig, ist der Auslöser weg —, nicht als Lösung.

Geht durch das Entfernen des Widgets etwas verloren?

Nur das Widget. Kontakte, Anrufverlauf und Vorschläge in Spotlight und Nachrichten funktionieren weiterhin; peopled läuft weiterhin bei Bedarf. Er wird nur nicht mehr aufgefordert, etwas zu aktualisieren, das er nicht aktualisieren kann.

Warum braucht das Lesen des CallHistoryDB-Ordners Festplattenvollzugriff?

Er enthält Ihr Anrufprotokoll, das macOS als sensible persönliche Daten behandelt und wie Nachrichten und Mail mit TCC schützt. Dieser Schutz ist der Grund, warum Terminal die Berechtigung benötigt, und auch, warum ein unerwartetes Quarantäne-Flag darauf so störend wirkt: Der Daemon hat nur einen einzigen, schmalen, sandboxed Zugangsweg zu den Daten, und alles, was diesen Weg blockiert, blockiert ihn vollständig.

Wird macOS 27 das beheben?

Unbekannt. Apple hat das Problem nicht bestätigt, und in den Beta-Versionshinweisen steht nichts dazu. Wenn der Mechanismus so ist, wie es die Indizien nahelegen, ist die Lösung klein — einmal fehlschlagen und keine weiteren Versuche mehr —, und sie könnte in jedem Punkt-Update ankommen, ohne erwähnt zu werden.

Fazit

Ein Mac, der heiß läuft, ohne etwas zu tun, hat fast immer einen Prozess in einer Schleife, und die Schleife hat fast immer eine banale Ursache. In diesem Fall ist es ein Daemon, dessen Aufgabe es ist, ein Widget aktuell zu halten, der durch jeden Anruf und jede Nachricht geweckt wird und der die eine Datenbank nicht lesen kann, die er braucht. Entfernen Sie das Widget, und die Anfragen hören auf; korrigieren Sie die Berechtigungen des Ordners, und die Lesezugriffe gelingen. Beides durchbricht die Schleife.

Wenn peopled bei Ihnen ganz oben in der Aktivitätsanzeige steht, arbeiten Sie die drei Lösungen der Reihe nach durch und starten Sie zwischendurch jeweils neu. Wenn es contactsd mit einem Exchange- oder Google-Konto ist, entfernen Sie das Konto. Und wenn es alle drei sind, mit accountsd an vorderster Stelle, probieren Sie alles Obige aus, entfernen Sie jedes Konto mit einer Warnung, und — weil Apple dazu seit fünf Monaten schweigt — reichen Sie den Feedback-Bericht mit der Sandbox-Log-Zeile ein, der das Problem vielleicht endlich beheben lässt.

Weiterführende Lektüre: Mac heiß und Akku leert sich nach macOS 26.6, WindowServer-CPU-Last unter 26.5 mit Liquid Glass, die Kontakte-App, die unter Tahoe nicht funktioniert, die Aktivitätsanzeige von Grund auf, und Widgets unter Tahoe anpassen.