Демон peopled перегружает процессор Mac на macOS Tahoe? Обычно виноват виджет «Контакты»

Ваш Mac греется, хотя ничего не делает. Оценка оставшегося заряда батареи упала вдвое. Вы открываете Мониторинг системы, сортируете список по загрузке процессора — и наверху видите процесс, о котором никогда не слышали: peopled, застрявший на отметке 70–80% и не желающий её отпускать. Или это contactsd. А на самых проблемных машинах — accountsd на уровне 180%, а следом за ним contactsd и itunescloudd. Завершить процесс бесполезно, потому что его нельзя завершить. Перезагрузка помогает — но лишь на час.

Это происходит с пользователями Mac начиная с macOS Tahoe 26.4 в марте, продолжает происходить на 26.5 и 26.6, Apple проблему не признала, а самое надёжное решение не встречается ни в одной из статей вида «перезагрузите Mac / сбросьте NVRAM», которые занимают верхние строчки поиска. Решение — удалить виджет.

В этом руководстве объясняется, что такое peopled (мы заглянули внутрь него), почему виджет вгоняет его в цикл, почему флаг карантина на папке, о существовании которой вы даже не подозревали, — это второй триггер, и в каком порядке пробовать решения.

Ключевые выводы

• peopled — это демон, отвечающий за виджет «Контакты». В его собственном бинарнике есть классы с именами WidgetSuggester, WidgetConfigurationReader и CallHistoryFetcher, а его песочница даёт ему доступ к базе данных истории звонков. Именно это сочетание и порождает цикл.
• Решение 1: удалите все виджеты «Контакты» — с рабочего стола, из Центра уведомлений и Пункта управления — а затем перезагрузите Mac. Это устранило проблему в большинстве из 54+ подтверждённых сообщений на форуме сообщества Apple.
• Решение 2: снимите флаг карантина с ~/Library/Application Support/CallHistoryDB и завершите процесс peopled. Это решение — когда удалять уже нечего; для него Terminal нужен Полный доступ к диску.
• Решение 3: отключите синхронизацию Контактов с iCloud, а затем включите её снова. Помогает не всем, и пока функция отключена, вы теряете синхронизацию.
• Всплески нагрузки от contactsd при наличии учётной записи Exchange или Google — это другая, более старая проблема с тем же симптомом, но другим решением: удалить учётную запись или использовать стороннее приложение.
• Apple не задокументировала решение. Ни в примечаниях к выпуску 26.4.1, 26.5, 26.6, ни 26.6.x об этом не упоминается, а сообщения о проблеме на 26.5 и более поздних версиях продолжают поступать.

Какой именно процесс

В этих сообщениях фигурируют три демона, и они не взаимозаменяемы. Отсортируйте Мониторинг системы по столбцу «% ЦП» и определите, какой из них у вас.

Process	What it belongs to	Typical report	Most likely cause
peopled	Фреймворк People — подсказки виджетов, «Семейный доступ», Экранное время, статус	Устойчиво 70–80% начиная с 26.4	Виджет «Контакты» + недоступная для чтения CallHistoryDB
contactsd	Фреймворк Contacts — база данных адресной книги и синхронизация	Всплески до 80% каждые 60–90 с, либо постоянная нагрузка	Цикл синхронизации контактов iCloud/Exchange/Google
accountsd	Фреймворк Accounts — каждая подключённая учётная запись	180% вместе с contactsd и itunescloudd	Цикл аутентификации учётной записи; выход из аккаунта часто не помогает

Если это peopled, начните с раздела про виджет. Если это только contactsd, переходите к разделу про синхронизацию учётных записей. Если нагружены все три демона, а accountsd — сильнее всех, вы столкнулись с наименее изученным вариантом, и в соответствующем разделе честно сказано, как мало о нём известно.

Что на самом деле делает peopled

Название намекает на контакты, и те немногие руководства, где демон вообще упоминается, описывают его как «управляет данными контактов». Это отчасти верно, но в существенных деталях неточно, и именно в этой разнице кроется причина, почему решение — это виджет, а не починка адресной книги.

Мы изучили этот демон на Mac с 26.5.2. Он находится по пути /System/Library/PrivateFrameworks/People.framework/peopled, а его задание launchd (/System/Library/LaunchAgents/com.apple.peopled.plist) показывает, что именно его будит. Он не загружается при входе в систему — RunAtLoad равно false. Он запускается событиями:

• Потоками Biome для missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest и childState
• Двумя системными уведомлениями: __ABDataBaseChangedByOtherProcessNotification (адресная книга изменилась) и _CalDatabaseChangedNotification (календарь изменился)

То есть каждый пропущенный звонок, каждое сообщение, каждое изменение контакта и каждое изменение в календаре будит peopled. А что он делает, проснувшись? Строки внутри его бинарника отвечают на это напрямую. Среди имён классов Swift:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

а среди шаблонов его сообщений в журнале:

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

Он линкуется с фреймворком Contacts, фреймворком CallHistory и двумя фреймворками Biome. Его задача, судя по собственному коду, — решать, каких людей показывать в виджете «Контакты» и в подсказках, связанных с людьми, используя ваши недавние звонки и сообщения в качестве сигнала.

Именно это объясняет механизм сбоя: демон, которого будит каждый звонок и сообщение, чья задача — обновлять виджет, и которому для этого нужно читать историю звонков.

Почему возникает цикл

Сопоставим фрагменты из ветки сообщества с тем, что говорит сам бинарник.

peopled работает внутри песочницы. Его профиль, расположенный по пути /System/Library/Sandbox/Profiles/com.apple.peopled.sb, начинается с (deny default), а затем открывает отдельные «двери». Вот две из них:

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

То есть ему разрешено читать ~/Library/Application Support/CallHistoryDB/, где macOS хранит базу данных звонков, сделанных и принятых через iPhone посредством Continuity. Эта папка также защищена TCC — на нашем Mac команда ls для неё из Terminal возвращает Operation not permitted, пока у Terminal нет Полного доступа к диску, — именно поэтому решения ниже требуют этого разрешения.

Теперь о сообщениях пользователей. 21 апреля один из участников ветки сообщества Apple процитировал сообщение ядра, которое он нашёл в Console, пока peopled крутился в цикле:

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

А 20 мая другой участник процитировал:

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

Трактовка, которая согласуется со всем этим: установлен виджет «Контакты», поэтому peopled просят его обновить; обновление означает получение истории звонков; в доступе отказано — потому что папка получила атрибут com.apple.quarantine, либо по какой-то другой причине с правами доступа, которую в сообщениях так и не установили точно, — обновление завершается неудачей, а следующее событие (или повторная попытка) запускает его снова. Демон, который после пропущенного звонка должен отработать миллисекунды, вместо этого работает непрерывно.

Мы хотим быть точны в том, что здесь установлено, а что нет. Имена классов, правила песочницы и сообщения журнала — это напрямую наблюдаемые факты; мы их прочитали сами. А то, что цикл выглядит как «обновление виджета — отказ в чтении — повтор», — это вывод, который согласуется со всеми виденными нами сообщениями и с обоими работающими решениями. Apple не подтвердила этот механизм, и не исключён второй триггер — один пользователь сообщает, что цикл начался после перестройки Пункта управления, хотя виджета «Контакты» там не было вовсе.

Сначала подтвердите диагноз, потом меняйте что-либо

Две минуты наблюдения экономят час гаданий, а характер нагрузки на процессор подсказывает, за какое решение браться.

Посмотрите на форму графика. В Мониторинге системы выберите процесс и посмотрите на историю загрузки процессора внизу окна, либо через Terminal:

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

peopled, застрявший на ровных 70–80%, — это цикл виджета. contactsd, который скачет вверх, падает до нуля и снова подскакивает через минуту, — это цикл синхронизации. Устойчивая нагрузка сразу от всех трёх демонов — это вариант с учётными записями.

Проверьте, как долго он выполняется. В норме peopled живёт секунды. На нашем (здоровом) Mac он находится в памяти уже 41 день при загрузке 0,0% — быть в памяти, но простаивать, это нормально. Вас должно насторожить сочетание «в памяти и занят»:

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

Найдите отказ в доступе. Это решающая проверка. Откройте второе окно Terminal и следите за журналом демона, пока он крутится в цикле:

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

а в первом окне поищите за последние несколько минут строку песочницы, которую цитируют в сообщениях сообщества:

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

Если вы видите deny(1) file-read-data применительно к CallHistoryDB, у вас вариант с CallHistoryDB, и сработает Решение 2. Если видите повторяющееся Event triggered widget refresh без отказа в доступе, начните с Решения 1. Если журнал молчит, а загрузка процессора высокая, значит цикл происходит в коде, который не пишет в журнал на уровне по умолчанию; всё равно попробуйте решения по порядку.

Понаблюдайте за файловой системой, если хотите полной уверенности. fs_usage показывает каждую файловую операцию, которую пытается выполнить процесс, включая неудачные:

sudo fs_usage -w -f filesys peopled

Экран, полностью заполненный попытками обращения к CallHistoryDB, завершающимися ошибками, — это и есть цикл, видимый в реальном времени.

Решение 1: удалите виджет «Контакты»

Это решение с наибольшим числом подтверждений, и его стоит пробовать первым, потому что оно обратимо и не требует Terminal.

Загвоздка в том, что на Mac с Tahoe виджет может находиться в трёх местах, и убрать его нужно из всех трёх.

Рабочий стол

Нажмите Control и щёлкните по обоям, затем выберите Изменить виджеты. У любого виджета «Контакты» на рабочем столе в режиме редактирования появляется кнопка удаления (минус в углу) — нажмите на неё. Либо нажмите Control и щёлкните по самому виджету, затем выберите Удалить виджет. Нажмите Готово.

Центр уведомлений

Щёлкните по дате и времени в строке меню, чтобы открыть Центр уведомлений, прокрутите до конца и нажмите Изменить виджеты. Удалите там любой виджет «Контакты» тем же способом — нажмите Control и щёлкните по нему, затем выберите Удалить виджет, либо нажмите Option и щёлкните по кнопке удаления.

Пункт управления

Именно это место чаще всего упускают из виду, потому что в Tahoe виджеты переехали в Пункт управления, а настройка находится не в Системных настройках. Щёлкните по значку Пункта управления в строке меню, выберите Изменить элементы управления и перетащите любой элемент «Контакты» за пределы Пункта управления. Нажмите Готово.

Затем перезагрузите Mac — просто выйти из системы недостаточно. В нескольких подтверждённых сообщениях в ветке отмечается, что загрузка процессора падала только после полной перезагрузки.

Ещё одно предостережение из той же ветки, отмеченное 31 июля: у некоторых пользователей цикл возобновлялся после повторного открытия галереи виджетов, даже без добавления виджета «Контакты». Если у вас была эта проблема, старайтесь избегать редактора виджетов, пока Apple не исправит демон.

Решение 2: снимите флаг карантина с CallHistoryDB

Для Mac, на которых нигде нет виджета «Контакты», либо где его удаление не помогло, — вот решение, к которому 20 мая пришёл автор самого технически подробного сообщения в ветке, и которое подтвердили как минимум ещё два пользователя («процесс peopled теперь потребляет 0% процессора», — написал один из них 26 июня).

Шаг 1: дайте Terminal Полный доступ к диску

Системные настройки > Конфиденциальность и безопасность > Полный доступ к диску, добавьте Terminal и включите переключатель. Без этого каждая команда ниже завершится ошибкой «Operation not permitted» — той же самой, что, как выясняется, получает и peopled. После выдачи разрешения перезапустите Terminal.

Шаг 2: посмотрите на папку

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

Флаг @ показывает расширенные атрибуты. Вы ищете com.apple.quarantine на самой папке или на файлах CallHistory.storedata внутри неё. Карантин — это флаг, который macOS ставит на скачанные файлы; ему совершенно нечего делать на системной базе данных, и как он туда попадает — неизвестно: восстановление из резервной копии и перенос данных с другого Mac — два вероятных пути.

Шаг 3: удалите его

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

-d удаляет атрибут, -r делает это рекурсивно, заходя внутрь папки.

Шаг 4: перезапустите демоны

sudo killall -9 peopled CallHistorySyncHelper

Оба будут перезапущены по требованию. Понаблюдайте за Мониторингом системы несколько минут.

Если флаг возвращается

Один из участников ветки сообщил 17 июля, что решение сработало, но флаг карантина «появился снова» за ночь. Если это произошло у вас, значит что-то заново помещает папку в карантин, и главные подозреваемые — инструмент резервного копирования или синхронизации, который воспринимает её как новые данные. Проверьте, что запускается ночью. Другой, более грубый вариант, к которому прибегнул ещё один пользователь, — удалить базу данных и дать macOS создать её заново:

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

При этом вы теряете хранящуюся на Mac копию истории звонков. Она заново наполняется с iPhone через Continuity. Это более радикальная мера, чем удаление атрибута, и мы бы сначала попробовали именно атрибут.

Решение 3: переключите синхронизацию Контактов с iCloud

Системные настройки > [ваше имя] > iCloud > Сохранено в iCloud > Контакты — отключите. Подождите минуту, понаблюдайте за загрузкой процессора. Если она упала, включите синхронизацию обратно и проверьте, останется ли нагрузка низкой.

Это помогает части пользователей и является стандартным советом в более старых ветках-предшественницах, уходящих на годы назад. У этого способа тоже есть свой сбой, с которым один пользователь столкнулся 11 мая: переключатель вообще не желал отключаться. Если это случилось и с вами, полностью выйдите из iCloud (сохранив копию данных, когда об этом спросят), перезагрузитесь, войдите снова. Отметим, что автор сообщения на V2EX с вариантом accountsd попробовал именно это, и после повторного входа нагрузка на процессор вернулась сразу же.

Если это contactsd, а у вас есть учётная запись Exchange или Google

Эта проблема существовала ещё до Tahoe, и её механизм понятнее.

contactsd — это демон фреймворка Contacts: он владеет базой данных адресной книги и сверяет её с каждой учётной записью, синхронизирующей контакты. Он также выполняет плановое обслуживание — его задание launchd регистрирует ежедневную задачу validate-cache, которая запускается только при питании от сети и в моменты вашей неактивности, а также повторяющуюся активность accounts.cleanup. Случайные кратковременные всплески загрузки от contactsd — это нормально.

Ненормально — это когда всплеск повторяется примерно раз в минуту. Один разработчик задокументировал именно это на Apple Developer Forums в декабре 2025 года: на M1 Max с Tahoe 26.1 учётная запись Office 365 с включёнными Контактами разгоняла AddressBookManager до 81%, а contactsd — до 22–59% по повторяющейся схеме каждые 60–90 секунд, причём даже с пустой папкой контактов Exchange на сервере, и это воспроизводилось на чистой установке. Та же учётная запись и те же данные не давали такого эффекта ни на Mac с M4, ни на iOS. Никто из Apple не ответил.

Его обходной путь — единственный, который действительно работает: удалить учётную запись Exchange в Системных настройках > Учётные записи в интернете, а если она нужна — использовать Outlook, который не проходит через фреймворк Contacts. В февральском сообщении на форуме сообщества про contactsd на MacBook Pro 2024 года с 26.3 дали такой же совет — отключить синхронизацию контактов из Exchange и Google и проверить результат, а если синхронизацию контактов ведут одновременно iCloud и учётная запись Google, для начала попробовать отключить именно Google.

Вариант с accountsd

Для самых тяжёлых случаев — accountsd на уровне 180% вместе с тянущимися следом contactsd и itunescloudd, на MacBook Air M5 с 26.5.2, описанных на V2EX в июле — подтверждённого решения нет. Автор сообщения отметил, что проблема начиналась каждое утро в одно и то же время, что указывает скорее на запланированную задачу, чем на событие виджета. Выход из системы и повторный вход не помогли.

Что мы можем добавить: accountsd — это демон фреймворка Accounts, который вызывается всякий раз, когда что-либо требует учётные данные для подключённой учётной записи, а itunescloudd — демон облачной библиотеки iTunes (Apple Music / Store). Все три демона одновременно означают, что что-то раз за разом запрашивает учётные данные аккаунта и получает отказ. Если у вас именно этот вариант, всё равно стоит попробовать решения выше по порядку, а если ни одно из них не сработает — проверьте, не проваливает ли аутентификацию какая-то одна учётная запись в Системных настройках > Учётные записи в интернете: старый вход в Google или Exchange, просроченный пароль приложения. Удалите всё, что помечено значком предупреждения.

Почему именно Tahoe и почему именно виджет

Виджеты существуют на Mac уже много лет, поэтому справедливо спросить, почему всё началось именно с 26.4. Одновременно изменились две вещи.

Первое — это то, где теперь живут виджеты. Tahoe добавила виджеты в Пункт управления в дополнение к рабочему столу и Центру уведомлений, а виджет «Контакты» в Пункте управления обновляется с другой периодичностью, чем такой же виджет на рабочем столе — собственные шаблоны журнала демона различают ежедневный проход «подсказать виджеты» («Last widget suggestion date is older 24 hours») и обновления по событию («Event triggered widget refresh»). Больше поверхностей — больше запросов на обновление — больше шансов, что неудачный запрос повторится.

Второе — похоже, что обработка ошибок в демоне устроена так, что он повторяет попытку, вместо того чтобы отступить. Это наш вывод из наблюдаемого поведения, а не то, что можно прочитать в самом бинарнике, и именно в этом настоящий баг: отказ в чтении должен один раз попасть в журнал, а обновление — быть отложено до следующего настоящего события. Вместо этого попытка повторяется, а события продолжают поступать.

Ни то, ни другое вы изменить не можете. Что вы можете изменить — это существует ли виджет и получает ли демон отказ в чтении, и именно на это направлены три описанных решения.

После того как проблема устранена

Есть несколько вещей, которые помогают сохранить результат.

Оставьте Terminal Полный доступ к диску, если вы использовали Решение 2, либо отзовите разрешение осознанно — подойдёт любой вариант, но важно понимать, какой именно вы выбрали, поскольку Полный доступ к диску для Terminal — это широкое разрешение.

Какое-то время избегайте галереи виджетов. Сообщение от 31 июля в ветке чётко указывает, что цикл возобновляло само её открытие — а не добавление чего-либо. Если вам нужно добавить другие виджеты, сделайте это, а затем проверьте Мониторинг системы.

После следующего обновления macOS проверьте снова. Промежуточные обновления у части пользователей заново добавляли стандартные элементы Пункта управления, и тихое возвращение виджета «Контакты» — самая вероятная причина повторного появления проблемы.

Отправьте отчёт. Feedback Assistant, категория macOS, приложите sysdiagnose, снятый во время высокой нагрузки на процессор (sudo sysdiagnose из Terminal, либо Shift-Control-Option-Command-Точка), и вставьте строку отказа песочницы. Пять месяцев обсуждений на форумах не сдвинули дело с места; несколько сотен отчётов Feedback с одинаковой строкой журнала, возможно, смогут.

Проблема уже исправлена?

Судя по всему, нет. Мы проверили примечания к обновлениям Tahoe: 26.4.1 «содержит исправления ошибок», 26.5 «включает улучшения, исправления ошибок и обновления безопасности», 26.6 оптимизирует индекс Spotlight, а 26.6.1 и 26.6.2 — это выпуски безопасности. Ни в одном не упоминаются Контакты, виджеты или загрузка процессора. В ветке сообщества сообщения продолжают поступать и на 26.5 («Проблема всё ещё существует в Tahoe 26.5. Apple нужно срочно это исправить», 15 мая), и вплоть до июля. Мы не встречали сообщений ни в ту, ни в другую сторону про 26.6.2, вышедшую 17 августа.

Если вы используете бета-версию macOS 27 и заметили — или не заметили — эту проблему, мы отслеживаем её в обзоре известных проблем беты.

С чем не стоит и связываться

Сброс NVRAM или SMC. Ни то, ни другое не имеет никакого отношения к правам доступа демона, работающего в пользовательском пространстве, к файлам. Пропустите.

tccutil reset All. Один пользователь попробовал — не помогло, а заодно снимает все разрешения конфиденциальности со всех приложений на Mac, на повторную выдачу которых потом уходит целый вечер. Нет никаких оснований считать, что виноват именно уровень TCC — отказ в журналах исходит от песочницы, а не от TCC.

Безопасный режим. Загрузка в безопасный режим и обратно очищает часть кэшей и на время облегчила ситуацию нескольким пользователям. По сути это перезагрузка с дополнительными шагами, которая не устраняет причину.

Отключение peopled через launchctl. Вы можете выполнить launchctl disable для этого агента, и он перестанет потреблять процессор, потому что просто перестанет работать. Заодно перестанут работать виджет «Контакты», подсказки по людям, механизм «запрос на покупку» Экранного времени и всё остальное, что от него зависит, а на Mac с защитой целостности системы это изменение может не пережить обновление. Не рекомендуется, разве что в качестве крайней меры для диагностики.

Решение частых проблем

Мониторинг системы показывает двадцать копий contactsd

Мы сами наблюдали это, пока писали статью: всплеск из двадцати процессов contactsd с последовательными PID, все — дочерние по отношению к launchd, все при 0% загрузки, и все исчезают в течение минуты. Это launchd порождает экземпляры под конкретных клиентов по требованию, и это не баг. Баг — это один процесс с высокой загрузкой, который никуда не исчезает.

Виджет «Контакты» удалён, а peopled всё равно на уровне 80%

Проверьте все три места — рабочий стол, Центр уведомлений, Пункт управления — а затем переходите к Решению 2. Если у вас никогда не было виджета «Контакты», сразу переходите к Решению 2.

xattr выводит «No such xattr: com.apple.quarantine»

Папка не в карантине, значит дело не в этом. Попробуйте Решение 3 и проверьте, не синхронизирует ли контакты учётная запись Exchange или Google.

ls для CallHistoryDB выдаёт «Operation not permitted» даже с sudo

sudo не обходит TCC. Самому Terminal нужен Полный доступ к диску, выданный в Системных настройках, после чего Terminal нужно перезапустить.

Проблема вернулась после обновления macOS

Обновления могут заново добавить виджет в стандартную раскладку Пункта управления. Проверьте все три места ещё раз.

Часто задаваемые вопросы

peopled — это вредоносное ПО?

Нет. Это подписанный демон Apple, расположенный по пути /System/Library/PrivateFrameworks/People.framework/peopled на запечатанном системном томе. Процесс с таким именем, запущенный из любого другого места, стоило бы проверить отдельно, но этот — родной, от Apple.

Можно просто завершить его принудительно?

sudo killall peopled останавливает его до следующего пробуждающего события, а на загруженном Mac это дело секунд. Это полезно как диагностика — если после завершения процесса загрузка остаётся низкой, значит триггер исчез, — но не как решение.

Теряется ли что-то при удалении виджета?

Теряется только сам виджет. Контакты, история звонков и подсказки в Spotlight и Сообщениях продолжают работать; peopled по-прежнему запускается, когда это нужно. Он просто перестаёт получать запросы на обновление того, что не может обновить.

Почему для чтения папки CallHistoryDB нужен Полный доступ к диску?

В ней хранится журнал ваших звонков, который macOS считает чувствительными личными данными и защищает через TCC — так же, как Сообщения и Почту. Именно из-за этой защиты Terminal нужно разрешение, и именно поэтому неожиданный флаг карантина на этой папке так разрушителен: у демона есть лишь один узкий, ограниченный песочницей путь к данным, и всё, что перекрывает этот путь, блокирует его полностью.

Исправит ли это macOS 27?

Неизвестно. Apple не признала проблему, и в примечаниях к бета-версии о ней ничего нет. Если механизм действительно таков, каким его рисуют имеющиеся данные, исправление должно быть небольшим — один раз получить отказ и прекратить повторные попытки, — и оно может появиться в любом промежуточном обновлении без каких-либо упоминаний.

Заключение

Если Mac греется, ничего не делая, почти всегда виноват один процесс, застрявший в цикле, а причина цикла почти всегда банальна. В данном случае это демон, чья задача — держать виджет актуальным, которого будит каждый звонок и сообщение, и который не может прочитать единственную нужную ему базу данных. Удалите виджет — и запросы прекратятся; исправьте права доступа к папке — и чтение будет успешным. Любой из этих шагов разрывает цикл.

Если peopled возглавляет список в Мониторинге системы, пройдите три решения по порядку, перезагружаясь между ними. Если это contactsd при наличии учётной записи Exchange или Google, удалите эту учётную запись. А если задействованы все три демона с accountsd во главе, попробуйте всё перечисленное выше, удалите любую учётную запись с предупреждением и — поскольку Apple молчит об этом уже пять месяцев — отправьте отчёт Feedback со строкой из журнала песочницы: возможно, именно это наконец сдвинет дело с мёртвой точки.

Дополнительное чтение: Mac греется и разряжается после macOS 26.6, нагрузка WindowServer на 26.5 с Liquid Glass, не работает приложение «Контакты» в Tahoe, Мониторинг системы с нуля и настройка виджетов в Tahoe.