¿peopled está saturando la CPU de tu Mac en macOS Tahoe? Normalmente es el widget de Contactos

macOSTahoe ·
¿peopled está saturando la CPU de tu Mac en macOS Tahoe? Normalmente es el widget de Contactos

¿peopled o contactsd atascado entre 70–180% de CPU tras una actualización de Tahoe, con el Mac caliente y la batería drenándose? La causa es un widget de Contactos que no puede leer tu historial de llamadas. Aquí está la solución que funciona.

Tu Mac está caliente sin hacer nada. La estimación de batería se ha reducido a la mitad. Abres Monitor de Actividad, ordenas por CPU, y arriba del todo hay un proceso que nunca habías visto — peopled — instalado en el 70 u 80 por ciento y sin moverse de ahí. O es contactsd. O, en las máquinas más afectadas, accountsd al 180% con contactsd e itunescloudd detrás. Forzar la salida no sirve de nada, porque no puedes forzar su salida. Reiniciar ayuda durante una hora.

Esto le viene pasando a los usuarios de Mac desde macOS Tahoe 26.4 en marzo, sigue pasando en 26.5 y 26.6, Apple no lo ha reconocido, y la solución más fiable no aparece en ninguno de los artículos de «reinicia tu Mac / restablece la NVRAM» que posicionan para esta búsqueda. Es eliminar un widget.

Esta guía explica qué es peopled (lo hemos mirado por dentro), por qué un widget lo mete en un bucle, por qué un indicador de cuarentena en una carpeta cuya existencia desconocías es el otro disparador, y el orden exacto en el que probar las soluciones.

Puntos clave

  • peopled es el daemon detrás del widget de Contactos. Su propio binario contiene clases llamadas WidgetSuggester, WidgetConfigurationReader y CallHistoryFetcher, y su perfil de sandbox le concede acceso a tu base de datos de historial de llamadas. Esa combinación es el bucle.
  • Solución 1: elimina todos los widgets de Contactos — escritorio, Centro de Notificaciones y Centro de Control — y luego reinicia. Esto resolvió la mayoría de los más de 54 casos confirmados en el foro comunitario de Apple.
  • Solución 2: elimina el indicador de cuarentena en ~/Library/Application Support/CallHistoryDB y mata peopled. Esta es la solución cuando no hay ningún widget que eliminar; requiere Acceso Total al Disco para Terminal.
  • Solución 3: desactiva Contactos de iCloud y vuelve a activarlo. Funciona para algunos, no para todos, y te cuesta la sincronización mientras está desactivado.
  • Los picos de contactsd con una cuenta de Exchange o Google son un bug diferente y más antiguo con el mismo síntoma y una solución distinta — eliminar la cuenta o usar un cliente de terceros.
  • Apple no ha documentado ninguna solución. Nada en las notas de la versión 26.4.1, 26.5, 26.6 o 26.6.x lo menciona, y los reportes en 26.5 y posteriores continúan.

Qué proceso, exactamente

Tres daemons aparecen en estos reportes y no son intercambiables. Ordena Monitor de Actividad por % CPU y anota cuál tienes.

ProcesoA qué perteneceReporte típicoCausa más probable
peopledPeople framework — sugerencias de widgets, Family, Screen Time, estado70–80% sostenido desde 26.4Widget de Contactos + CallHistoryDB ilegible
contactsdContacts framework — la base de datos de la agenda y su sincronizaciónPicos al 80% cada 60–90 s, o sostenidoBucle de sincronización de contactos de iCloud/Exchange/Google
accountsdAccounts framework — cada cuenta con sesión iniciada180% junto a contactsd e itunesclouddBucle de autenticación de cuenta; la solución de cerrar sesión suele fallar

Si es peopled, empieza por la sección del widget. Si es solo contactsd, salta a la sección de sincronización de cuentas. Si son los tres con accountsd a la cabeza, estás en la variante menos comprendida, y la sección sobre ella es honesta acerca de lo poco que se sabe.

Qué hace realmente peopled

El nombre sugiere contactos, y las guías que lo mencionan siquiera lo describen como que «gestiona los datos de contactos». Eso es aproximadamente correcto y específicamente incorrecto, y la diferencia es la razón por la que la solución es un widget en lugar de una reparación de la agenda.

Miramos el daemon en un Mac con 26.5.2. Vive en /System/Library/PrivateFrameworks/People.framework/peopled, y su trabajo de launchd (/System/Library/LaunchAgents/com.apple.peopled.plist) te dice qué lo despierta. No se carga al iniciar sesión — RunAtLoad está en false. Se inicia por eventos:

  • Flujos de Biome para missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest y childState
  • Dos notificaciones del sistema: __ABDataBaseChangedByOtherProcessNotification (la agenda cambió) y _CalDatabaseChangedNotification (el calendario cambió)

Así que cada llamada perdida, cada mensaje, cada edición de contacto y cada cambio de calendario despierta a peopled. ¿Y qué hace cuando se despierta? Las cadenas en su binario lo responden directamente. Entre los nombres de clase de Swift:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

y entre sus plantillas de mensajes de log:

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

Enlaza el Contacts framework, el CallHistory framework y dos frameworks de Biome. Su propósito, según lo describe su propio código, es decidir a qué personas mostrar en el widget de Contactos y en las sugerencias relacionadas con personas, usando tus llamadas y mensajes recientes como señal.

Eso es lo que hace que el fallo tenga sentido: un daemon que se despierta con cada llamada y mensaje, cuyo trabajo es refrescar un widget, y que necesita leer el historial de llamadas para hacerlo.

Dentro del daemon peopled en macOS Tahoe

Por qué entra en bucle

Pon las piezas del hilo comunitario junto a lo que dice el binario.

peopled se ejecuta dentro de un sandbox. Su perfil, en /System/Library/Sandbox/Profiles/com.apple.peopled.sb, empieza con (deny default) y luego abre puertas específicas. Dos de ellas:

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

Así que tiene permiso para leer ~/Library/Application Support/CallHistoryDB/, donde macOS guarda la base de datos de llamadas hechas y recibidas a través de tu iPhone vía Continuity. Esa carpeta también está protegida por TCC — en nuestro Mac, un ls sobre ella desde Terminal devuelve Operation not permitted hasta que Terminal tiene Acceso Total al Disco — que es por lo que las soluciones de abajo necesitan ese permiso.

Ahora los reportes. El 21 de abril, un usuario en el hilo comunitario de Apple citó el mensaje del kernel que encontró en Console mientras peopled estaba girando:

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

Y el 20 de mayo otro citó:

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

La lectura que encaja con todo esto: hay un widget de Contactos instalado, así que se le pide a peopled que lo refresque; refrescar significa obtener el historial de llamadas; la obtención es denegada — porque la carpeta ha adquirido un atributo com.apple.quarantine, o por alguna otra razón de permisos que los reportes no han logrado precisar — el refresco falla, y el siguiente evento (o el reintento) lo dispara de nuevo. Un daemon que debería ejecutarse durante milisegundos tras una llamada perdida se ejecuta continuamente en su lugar.

Queremos ser precisos sobre qué está y qué no está establecido aquí. Los nombres de clase, las reglas de sandbox y los mensajes de log son directamente observables; los leímos. Que el bucle sea «refresco de widget, lectura denegada, reintento» es una inferencia que encaja con cada reporte que hemos visto y con ambas soluciones que funcionan. Apple no ha confirmado el mecanismo, y podría haber un segundo disparador — un usuario reporta que el bucle empezó tras reorganizar el Centro de Control sin ningún widget de Contactos presente en absoluto.

Confírmalo antes de cambiar nada

Dos minutos de observación ahorran una hora de conjeturas, y el patrón del uso de CPU te dice qué solución elegir.

Observa la forma del uso. En Monitor de Actividad, selecciona el proceso y mira el historial de CPU en el pie de la ventana, o desde Terminal:

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

Un peopled que se mantiene plano en 70–80% es el bucle del widget. Un contactsd que sube, cae a cero, y sube de nuevo un minuto después es el bucle de sincronización. CPU sostenida en los tres daemons a la vez es la variante de cuentas.

Comprueba cuánto lleva ejecutándose. peopled normalmente vive durante segundos. En nuestro Mac (sano) lleva 41 días residente al 0.0% de CPU — residente pero inactivo está bien. Lo que buscas es residente y ocupado:

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

Busca la denegación. Esta es la prueba decisiva. Abre una segunda ventana de Terminal y transmite el log del daemon mientras está girando:

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

y, en la primera ventana, busca en los últimos minutos la línea de sandbox que citan los reportes comunitarios:

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

Si ves deny(1) file-read-data contra CallHistoryDB, tienes la variante de CallHistoryDB y la Solución 2 es la que funcionará. Si ves Event triggered widget refresh repitiéndose sin una denegación, empieza con la Solución 1. Si el log está en silencio y la CPU está alta, el bucle está en código que no registra en el nivel por defecto; prueba las soluciones en orden de todos modos.

Observa el sistema de archivos, si quieres certeza. fs_usage muestra cada operación de archivo que intenta un proceso, incluidas las que fallan:

sudo fs_usage -w -f filesys peopled

Una pantalla llena de intentos sobre CallHistoryDB devolviendo errores es el bucle, visible en tiempo real.

Solución 1: eliminar el widget de Contactos

Esta es la solución con más confirmaciones, y es la que hay que probar primero porque es reversible y no necesita Terminal.

El detalle es que hay tres lugares donde puede vivir un widget en un Mac con Tahoe, y tiene que desaparecer de los tres.

Escritorio

Haz clic secundario en el fondo de pantalla y elige Editar widgets. Cualquier widget de Contactos en el escritorio muestra un botón de eliminar (el signo menos en la esquina) mientras editas; haz clic en él. Alternativamente, haz clic secundario en el propio widget y elige Eliminar widget. Haz clic en Listo.

Centro de Notificaciones

Haz clic en la fecha y hora de la barra de menús para abrir el Centro de Notificaciones, desplázate hasta el final, haz clic en Editar widgets. Elimina cualquier widget de Contactos ahí de la misma forma — clic secundario y Eliminar widget, u Option-clic en su botón de eliminar.

Centro de Control

Este es el que la gente se salta, porque Tahoe trasladó los widgets al Centro de Control y la personalización no está en Ajustes del Sistema. Haz clic en el icono del Centro de Control en la barra de menús, elige Editar controles, y arrastra cualquier elemento de Contactos fuera del Centro de Control. Haz clic en Listo.

Luego reinicia — no solo cierres sesión. Varias soluciones confirmadas en el hilo señalan que la CPU solo bajó tras un reinicio completo.

Una advertencia adicional del mismo hilo, reportada el 31 de julio: para algunos usuarios el bucle volvió después de abrir de nuevo la galería de widgets, incluso sin añadir el widget de Contactos. Si has tenido este problema, trata el editor de widgets como algo que evitar hasta que Apple arregle el daemon.

Solución 2: eliminar el indicador de cuarentena en CallHistoryDB

Para Macs sin ningún widget de Contactos en ninguna parte, o donde eliminarlo no ayudó, esta es la solución a la que llegó el reporte técnicamente más detallado del hilo el 20 de mayo, y que al menos otros dos usuarios confirmaron («el proceso peopled está ahora en 0% de consumo de CPU», escribió uno el 26 de junio).

Paso 1: da a Terminal Acceso Total al Disco

Ajustes del Sistema > Privacidad y Seguridad > Acceso Total al Disco, añade Terminal, y actívalo. Sin esto, cada comando de abajo falla con «Operation not permitted» — que, da la casualidad, es el mismo error que está teniendo peopled. Reinicia Terminal después de conceder el permiso.

Paso 2: mira la carpeta

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

La opción @ muestra los atributos extendidos. Lo que buscas es com.apple.quarantine en la carpeta o en los archivos CallHistory.storedata dentro de ella. Cuarentena es el indicador que macOS pone en los archivos descargados; no tiene ningún motivo para estar en una base de datos del sistema, y cómo llega ahí no se sabe — una restauración desde una copia de seguridad y una migración desde otro Mac son las dos rutas plausibles.

Paso 3: elimínalo

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

-d borra el atributo, -r recorre la carpeta de forma recursiva.

Paso 4: reinicia los daemons

sudo killall -9 peopled CallHistorySyncHelper

Ambos se relanzarán bajo demanda. Observa Monitor de Actividad durante unos minutos.

Si el indicador vuelve

Un usuario en el hilo reportó el 17 de julio que la solución funcionó y el indicador de cuarentena «reapareció» durante la noche. Si te pasa esto, algo está volviendo a poner en cuarentena la carpeta, y los candidatos son una herramienta de copia de seguridad o sincronización que la trata como datos nuevos. Comprueba qué se ejecuta de noche. Alternativamente, y de forma más contundente, el enfoque de otro usuario fue eliminar la base de datos y dejar que macOS la recree:

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

Pierdes la copia del Mac de tu historial de llamadas. Se repuebla desde el iPhone a través de Continuity. Este es un martillo más grande que eliminar un atributo, y nosotros probaríamos primero el atributo.

Solución 3: alternar Contactos de iCloud

Ajustes del Sistema > [tu nombre] > iCloud > Guardado en iCloud > Contactos, desactívalo. Espera un minuto, observa la CPU. Si baja, vuelve a activarlo y comprueba si se mantiene bajo.

Esto funciona para un subconjunto de usuarios y es el consejo estándar en los hilos hermanos más antiguos del mismo tema, que se remontan años atrás. También tiene un modo de fallo que un usuario encontró el 11 de mayo: el interruptor no se desactivaba en absoluto. Si te pasa esto, cierra sesión de iCloud por completo (conservando una copia de los datos cuando se te pregunte), reinicia, vuelve a iniciar sesión. Ten en cuenta que el usuario de V2EX con la variante de accountsd probó exactamente esto y la CPU volvió de inmediato tras iniciar sesión de nuevo.

Eliminando el widget de Contactos y limpiando la cuarentena de CallHistoryDB en macOS Tahoe

Si es contactsd y tienes una cuenta de Exchange o Google

Este caso es anterior a Tahoe y tiene un mecanismo más claro.

contactsd es el daemon del Contacts framework: posee la base de datos de la agenda y la reconcilia con cada cuenta que sincroniza contactos. También hace tareas de mantenimiento programadas — su trabajo de launchd registra una tarea diaria validate-cache que solo se ejecuta con alimentación externa mientras estás inactivo, y una actividad repetitiva accounts.cleanup. Un uso de CPU ocasional y breve de contactsd es normal.

Lo que no es normal es un pico cada minuto aproximadamente. Un desarrollador documentó exactamente esto en los foros de Apple Developer en diciembre de 2025: en un M1 Max con Tahoe 26.1, una cuenta de Office 365 con Contactos activado llevó AddressBookManager al 81% y contactsd al 22–59% en un patrón repetido cada 60–90 segundos — incluso con la carpeta de contactos de Exchange vaciada en el servidor, y reproducible en una instalación limpia. La misma cuenta y datos no lo hicieron en un Mac M4 ni en iOS. Nadie de Apple respondió.

Su solución alternativa es la que funciona: elimina la cuenta de Exchange en Ajustes del Sistema > Cuentas de Internet, y si la necesitas, usa Outlook, que no pasa por el Contacts framework. Un reporte de febrero en el foro comunitario con contactsd en un MacBook Pro de 2024 con 26.3 recibió el consejo equivalente — dejar de sincronizar contactos desde Exchange y Google y probar — y si tienes tanto iCloud como una cuenta de Google sincronizando contactos, prueba a eliminar Google primero.

La variante accountsd

Los reportes más severos — accountsd al 180% con contactsd e itunescloudd a la zaga, en un MacBook Air M5 con 26.5.2, descrito en V2EX en julio — no tienen una solución confirmada. El autor del reporte señaló que empezaba a la misma hora cada mañana, lo cual apunta a una tarea programada más que a un evento de widget. Cerrar sesión y volver a iniciarla no ayudó.

Lo que podemos añadir: accountsd es el daemon del Accounts framework y se invoca cada vez que algo necesita una credencial para una cuenta con sesión iniciada, e itunescloudd es el daemon de la biblioteca de iTunes Cloud (Apple Music / Store). Los tres a la vez significan que algo está pidiendo credenciales de cuenta repetidamente y fallando. Si tienes esta variante, las soluciones anteriores siguen valiendo la pena probarlas en orden, y si ninguna funciona, merece la pena comprobar si una sola cuenta — un inicio de sesión antiguo de Google o Exchange, una contraseña específica de aplicación caducada — está fallando la autenticación en Ajustes del Sistema > Cuentas de Internet. Elimina cualquiera que muestre un distintivo de advertencia.

Por qué Tahoe, y por qué un widget

Los widgets han existido en el Mac durante años, así que es justo preguntar por qué esto empezó con 26.4. Dos cosas cambiaron a la vez.

La primera es dónde viven los widgets. Tahoe puso los widgets en el Centro de Control junto al escritorio y el Centro de Notificaciones, y un widget de Contactos en el Centro de Control se refresca con una cadencia distinta a uno que está en el escritorio — las propias plantillas de log del daemon distinguen un paso diario de «sugerir widgets» («Last widget suggestion date is older 24 hours») de los refrescos disparados por eventos («Event triggered widget refresh»). Más superficies, más solicitudes de refresco, más ocasiones para que un intento fallido se reintente.

La segunda es que el manejo de errores del daemon parece reintentar en lugar de retroceder. Esa es nuestra inferencia a partir del comportamiento, no algo que podamos leer en el binario, y es el bug real: una lectura denegada debería registrarse una vez y el refresco abandonarse hasta el siguiente evento genuino. En cambio, se vuelve a intentar, y los eventos siguen llegando.

Ninguna de las dos cosas es algo que puedas cambiar. Lo que sí puedes cambiar es si el widget existe y si la lectura es denegada, que es lo que hacen las tres soluciones.

Una vez solucionado

Unas cuantas cosas lo mantienen solucionado.

Deja el Acceso Total al Disco de Terminal como está si usaste la Solución 2, o revócalo deliberadamente — cualquiera de las dos opciones está bien, pero ten claro cuál hiciste, porque Terminal con Acceso Total al Disco es un permiso amplio.

Evita la galería de widgets durante un tiempo. El reporte del 31 de julio en el hilo es específico en que abrirla — no añadir nada — reinició el bucle. Si quieres añadir otros widgets, hazlo, y luego comprueba Monitor de Actividad después.

Tras la siguiente actualización de macOS, revisa de nuevo. Las actualizaciones puntuales han vuelto a añadir elementos por defecto al Centro de Control para algunos usuarios, y que un widget de Contactos regrese silenciosamente es la razón más probable de que el problema vuelva.

Presenta el reporte. Feedback Assistant, categoría macOS, adjunta un sysdiagnose tomado mientras la CPU está alta (sudo sysdiagnose desde Terminal, o Mayúsculas-Control-Option-Comando-Punto), y pega la línea de denegación del sandbox. Cinco meses de hilos en el foro no han movido esto; unos cientos de reportes de Feedback con la misma línea de log podrían hacerlo.

¿Está ya solucionado?

No, hasta donde se puede saber. Revisamos las notas de actualización de Apple para Tahoe: 26.4.1 «incluye correcciones de errores», 26.5 «incluye mejoras, correcciones de errores y actualizaciones de seguridad», 26.6 optimiza el índice de Spotlight, y 26.6.1 y 26.6.2 son versiones de seguridad. Ninguna menciona Contactos, widgets o CPU. En el hilo comunitario, los reportes continúan en 26.5 («El problema todavía existe en Tahoe 26.5. Apple necesita arreglar esto cuanto antes», el 15 de mayo) y hasta julio. No hemos visto ningún reporte en un sentido u otro para 26.6.2, que se lanzó el 17 de agosto.

Si estás en la beta de macOS 27 y has visto esto o no, el resumen de problemas conocidos de la beta es donde lo seguimos.

Qué no merece la pena probar

Restablecer la NVRAM o la SMC. Ninguna de las dos tiene nada que ver con los permisos de archivo de un daemon en espacio de usuario. Sáltatelo.

tccutil reset All. Un usuario lo probó; no ayudó, y elimina todos los permisos de privacidad de todas las apps del Mac, lo que luego te cuesta toda una tarde volver a conceder. No hay razón para pensar que TCC sea la capa responsable — la denegación en los logs es el sandbox, no TCC.

Modo Seguro. Arrancar en Modo Seguro y volver limpia algunas cachés y dio a algunos usuarios un alivio temporal. Es un reinicio con pasos adicionales y no aborda la causa.

Desactivar peopled con launchctl. Puedes hacer launchctl disable del agente, y dejará de consumir CPU porque dejará de ejecutarse. También detendrá el widget de Contactos, las sugerencias de personas, la infraestructura de «pedir permiso para comprar» de Screen Time y cualquier otra cosa que dependa de él, y en un Mac con protección de integridad del sistema el cambio puede no sobrevivir a una actualización. No recomendado salvo como diagnóstico de último recurso.

Solución de problemas comunes

Monitor de Actividad muestra veinte copias de contactsd

Vimos esto nosotros mismos mientras escribíamos: una ráfaga de veinte procesos contactsd con PID consecutivos, todos hijos de launchd, todos al 0% de CPU, desaparecidos en un minuto. Eso es launchd generando instancias por cliente bajo demanda, y no es el bug. El bug es un proceso con CPU alta que se queda.

El widget de Contactos ha desaparecido pero peopled sigue al 80%

Comprueba las tres ubicaciones — escritorio, Centro de Notificaciones, Centro de Control — y luego pasa a la Solución 2. Si nunca tuviste un widget de Contactos, ve directamente a la Solución 2.

xattr dice «No such xattr: com.apple.quarantine»

La carpeta no está en cuarentena, así que ese no es tu disparador. Prueba la Solución 3, y comprueba si tienes una cuenta de Exchange o Google sincronizando contactos.

ls en CallHistoryDB dice «Operation not permitted» incluso con sudo

sudo no salta TCC. Terminal necesita Acceso Total al Disco, concedido en Ajustes del Sistema, y luego relanzarse.

Volvió después de una actualización de macOS

Las actualizaciones pueden volver a añadir el widget a la disposición por defecto del Centro de Control. Comprueba las tres ubicaciones de nuevo.

Preguntas frecuentes

¿Es peopled malware?

No. Es un daemon de Apple firmado en /System/Library/PrivateFrameworks/People.framework/peopled en el volumen del sistema sellado. Un proceso con ese nombre ejecutándose desde cualquier otro sitio sí merecería investigarse; este es de Apple.

¿Puedo simplemente matarlo?

sudo killall peopled lo detiene hasta que el siguiente evento lo despierte, que en un Mac ocupado son segundos. Es útil como diagnóstico — si la CPU se mantiene baja tras matarlo, el disparador ha desaparecido — no como solución.

¿Eliminar el widget hace que pierda algo?

Solo el widget. Contactos, el historial de llamadas y las sugerencias en Spotlight y Mensajes siguen funcionando todos; peopled sigue ejecutándose cuando se necesita. Simplemente deja de que se le pida refrescar algo que no puede refrescar.

¿Por qué la carpeta CallHistoryDB necesita Acceso Total al Disco para leerse?

Contiene tu registro de llamadas, que macOS trata como datos personales sensibles y protege con TCC igual que Mensajes y Mail. Esa protección es la razón por la que Terminal necesita el permiso, y también es la razón por la que un indicador de cuarentena inesperado en ella resulta tan disruptivo: el daemon tiene una única vía estrecha y en sandbox hacia los datos, y cualquier cosa que bloquee esa vía lo bloquea por completo.

¿Lo arreglará macOS 27?

Desconocido. Apple no ha reconocido el problema, y no hay nada en las notas de la beta al respecto. Si el mecanismo es el que sugiere la evidencia, la solución es pequeña — fallar una vez y dejar de reintentar — y podría llegar en cualquier versión puntual sin ser mencionada.

Conclusión

Un Mac que se calienta sin hacer nada casi siempre tiene un proceso en bucle, y el bucle casi siempre tiene una causa mundana. Este es un daemon cuyo trabajo es mantener fresco un widget, que se despierta con cada llamada y mensaje, y que no puede leer la única base de datos que necesita. Elimina el widget y las solicitudes se detienen; arregla los permisos de la carpeta y las lecturas tienen éxito. Cualquiera de las dos rompe el bucle.

Si tienes peopled en lo más alto de Monitor de Actividad, trabaja las tres soluciones en orden y reinicia entre ellas. Si es contactsd con una cuenta de Exchange o Google, elimina la cuenta. Y si son los tres con accountsd al frente, prueba todo lo anterior, elimina cualquier cuenta que muestre una advertencia, y — porque Apple ha guardado silencio sobre esto durante cinco meses — presenta el reporte de Feedback, con la línea de log del sandbox, que podría finalmente conseguir que se arregle.

Lectura relacionada: Mac caliente y con la batería drenándose tras macOS 26.6, CPU de WindowServer en 26.5 con Liquid Glass, la app Contactos que no funciona en Tahoe, Monitor de Actividad desde cero, y personalizar los widgets en Tahoe.