peopled travando a CPU do seu Mac no macOS Tahoe? Geralmente é o widget de Contatos

Seu Mac está quente sem fazer nada. A estimativa de bateria caiu pela metade. Você abre o Monitor de Atividade, ordena por CPU, e no topo está um processo que você nunca ouviu falar — peopled — parado em 70 ou 80 por cento e permanecendo ali. Ou é o contactsd. Ou, nas máquinas mais afetadas, accountsd em 180% com contactsd e itunescloudd logo atrás. Encerrar não faz nada, porque você não consegue encerrá-los. Reiniciar ajuda por uma hora.

Isso vem acontecendo com usuários de Mac desde o macOS Tahoe 26.4 em março, ainda está acontecendo no 26.5 e no 26.6, a Apple não reconheceu o problema, e a correção mais confiável não está em nenhum dos artigos de "reinicie seu Mac / redefina a NVRAM" que aparecem bem posicionados na busca. É remover um widget.

Este guia explica o que é o peopled (nós olhamos por dentro dele), por que um widget o coloca em loop, por que um sinalizador de quarentena numa pasta que você nem sabia que existia é o outro gatilho, e a ordem exata em que tentar as correções.

Principais conclusões

• peopled é o daemon por trás do widget de Contatos. Seu próprio binário contém classes chamadas WidgetSuggester, WidgetConfigurationReader e CallHistoryFetcher, e seu perfil de sandbox concede a ele acesso ao seu banco de dados de histórico de chamadas. Essa combinação é o loop.
• Correção 1: remova todo widget de Contatos — na área de trabalho, na Central de Notificações e na Central de Controle — e reinicie. Isso resolveu a maioria dos mais de 54 relatos confirmados no fórum da comunidade da Apple.
• Correção 2: limpe o sinalizador de quarentena em ~/Library/Application Support/CallHistoryDB e encerre o peopled. Essa é a correção quando não há widget algum para remover; ela exige Acesso Total ao Disco para o Terminal.
• Correção 3: desative os Contatos do iCloud e reative-os. Funciona para alguns, não para todos, e custa a sincronização enquanto está desativada.
• Picos do contactsd com uma conta Exchange ou Google são um bug diferente, mais antigo, com o mesmo sintoma e uma correção diferente — remover a conta ou usar um cliente de terceiros.
• A Apple não documentou uma correção. Nada nas notas de versão do 26.4.1, 26.5, 26.6 ou 26.6.x menciona isso, e os relatos no 26.5 e versões posteriores continuam.

Qual processo, exatamente

Três daemons aparecem nesses relatos e eles não são intercambiáveis. Ordene o Monitor de Atividade por % CPU e anote qual você tem.

Processo	A que pertence	Relato típico	Causa mais provável
peopled	Framework People — sugestões de widget, Família, Tempo de Uso, status	70–80% sustentado desde o 26.4	Widget de Contatos + CallHistoryDB ilegível
contactsd	Framework Contacts — o banco de dados da agenda e sincronização	Picos de 80% a cada 60–90 s, ou sustentado	Loop de sincronização de contatos do iCloud/Exchange/Google
accountsd	Framework Accounts — toda conta conectada	180% junto com contactsd e itunescloudd	Loop de autenticação de conta; a correção de sair da conta frequentemente falha

Se for o peopled, comece pela seção do widget. Se for só o contactsd, vá direto para a seção de conta sincronizada. Se forem os três com o accountsd no topo, você está na variante menos compreendida, e a seção sobre ela é honesta quanto ao pouco que se sabe.

O que o peopled realmente faz

O nome sugere contatos, e os guias que sequer o mencionam o descrevem como algo que "gerencia dados de contato". Isso está aproximadamente certo e especificamente errado, e a diferença é o motivo pelo qual a correção é um widget, e não um reparo na agenda.

Examinamos o daemon em um Mac rodando 26.5.2. Ele fica em /System/Library/PrivateFrameworks/People.framework/peopled, e seu job do launchd (/System/Library/LaunchAgents/com.apple.peopled.plist) revela o que o desperta. Ele não é carregado no login — RunAtLoad é false. Ele é iniciado por eventos:

• Streams do Biome para missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest e childState
• Duas notificações do sistema: __ABDataBaseChangedByOtherProcessNotification (a agenda mudou) e _CalDatabaseChangedNotification (o calendário mudou)

Então toda chamada perdida, toda mensagem, toda edição de contato e toda mudança de calendário desperta o peopled. E o que ele faz quando é despertado? As strings em seu binário respondem isso diretamente. Entre os nomes de classe Swift:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

e entre seus modelos de mensagem 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

Ele vincula o framework Contacts, o framework CallHistory e dois frameworks do Biome. Seu propósito, tanto quanto o próprio código descreve, é decidir quais pessoas exibir no widget de Contatos e em sugestões relacionadas a pessoas, usando suas chamadas e mensagens recentes como sinal.

É isso que faz o modo de falha fazer sentido: um daemon que é despertado por toda chamada e mensagem, cujo trabalho é atualizar um widget, e que precisa ler o histórico de chamadas para fazer isso.

Por que ele entra em loop

Coloque as peças da thread da comunidade lado a lado com o que o binário diz.

O peopled roda dentro de um sandbox. Seu perfil, em /System/Library/Sandbox/Profiles/com.apple.peopled.sb, começa com (deny default) e depois abre portas específicas. Duas delas:

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

Então ele tem permissão para ler ~/Library/Application Support/CallHistoryDB/, onde o macOS mantém o banco de dados de chamadas feitas e recebidas pelo seu iPhone via Continuidade. Essa pasta também é protegida pelo TCC — no nosso Mac, ls nela pelo Terminal retorna Operation not permitted até que o Terminal tenha Acesso Total ao Disco — o que explica por que as correções abaixo exigem essa permissão.

Agora os relatos. Em 21 de abril, um usuário na thread da comunidade da Apple citou a mensagem do kernel que encontrou no Console enquanto o peopled estava girando:

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

E em 20 de maio outro citou:

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

A leitura que se encaixa em tudo isso: um widget de Contatos está instalado, então o peopled é solicitado a atualizá-lo; atualizar significa buscar o histórico de chamadas; a busca é negada — porque a pasta adquiriu um atributo com.apple.quarantine, ou por algum outro motivo de permissão que os relatos ainda não identificaram com precisão — a atualização falha, e o próximo evento (ou a nova tentativa) o dispara de novo. Um daemon que deveria rodar por milissegundos após uma chamada perdida, em vez disso, roda continuamente.

Queremos ser precisos sobre o que está e o que não está estabelecido aqui. Os nomes de classe, as regras de sandbox e as mensagens de log são diretamente observáveis; nós as lemos. Que o loop seja "atualização de widget, leitura negada, nova tentativa" é uma inferência que se encaixa em todo relato que vimos e em ambas as correções que funcionam. A Apple não confirmou o mecanismo, e pode haver um segundo gatilho — um usuário relata que o loop começou depois de reorganizar a Central de Controle sem nenhum widget de Contatos presente.

Confirme antes de mudar qualquer coisa

Dois minutos de observação poupam uma hora de tentativa e erro, e o padrão do uso de CPU indica qual correção buscar.

Observe o formato. No Monitor de Atividade, selecione o processo e veja o histórico de CPU no rodapé da janela, ou pelo Terminal:

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

Um peopled parado em um plano de 70–80% é o loop do widget. Um contactsd que dispara, cai a zero e dispara de novo um minuto depois é o loop de sincronização. CPU sustentada nos três daemons ao mesmo tempo é a variante de conta.

Verifique há quanto tempo está rodando. O peopled normalmente vive por segundos. No nosso Mac (saudável), ele está residente há 41 dias com 0,0% de CPU — residente porém ocioso é normal. O que você procura é residente e ocupado:

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

Procure pela negação. Esse é o teste decisivo. Abra uma segunda janela do Terminal e transmita o log do daemon enquanto ele está girando:

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

e, na primeira janela, busque nos últimos minutos pela linha de sandbox que os relatos da comunidade citam:

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

Se você ver deny(1) file-read-data contra CallHistoryDB, você tem a variante do CallHistoryDB e a Correção 2 é a que vai funcionar. Se você ver Event triggered widget refresh se repetindo sem uma negação, comece pela Correção 1. Se o log está silencioso e a CPU está alta, o loop está em um código que não registra log no nível padrão; tente as correções na ordem mesmo assim.

Observe o sistema de arquivos, se quiser certeza. O fs_usage mostra toda operação de arquivo que um processo tenta, incluindo as que falham:

sudo fs_usage -w -f filesys peopled

Uma tela cheia de tentativas em CallHistoryDB retornando erros é o loop, visível em tempo real.

Correção 1: remova o widget de Contatos

Essa é a correção com mais confirmações, e é a primeira a tentar porque é reversível e não exige Terminal.

O problema é que há três lugares onde um widget pode existir em um Mac com Tahoe, e ele precisa desaparecer de todos eles.

Área de trabalho

Control-clique no papel de parede e escolha Editar Widgets. Qualquer widget de Contatos na área de trabalho mostra um botão de remoção (o sinal de menos no canto) durante a edição; clique nele. Alternativamente, Control-clique no próprio widget e escolha Remover Widget. Clique em Concluído.

Central de Notificações

Clique na data e hora na barra de menus para abrir a Central de Notificações, role até o fim, clique em Editar Widgets. Remova qualquer widget de Contatos ali da mesma forma — Control-clique e Remover Widget, ou Option-clique no botão de remoção dele.

Central de Controle

Esse é o que as pessoas costumam esquecer, porque o Tahoe moveu os widgets para a Central de Controle e a personalização não está nos Ajustes do Sistema. Clique no ícone da Central de Controle na barra de menus, escolha Editar Controles, e arraste qualquer item de Contatos para fora da Central de Controle. Clique em Concluído.

Depois reinicie — não apenas encerre a sessão. Várias correções confirmadas na thread apontam que a CPU só caiu depois de um reinício completo.

Uma precaução adicional da mesma thread, relatada em 31 de julho: para alguns usuários o loop voltou depois que eles abriram a galeria de widgets de novo, mesmo sem adicionar o widget de Contatos. Se você já teve esse problema, trate o editor de widgets como algo a evitar até que a Apple corrija o daemon.

Correção 2: limpe o sinalizador de quarentena no CallHistoryDB

Para Macs sem nenhum widget de Contatos em lugar algum, ou onde removê-lo não ajudou, essa é a correção a que chegou o relato mais tecnicamente detalhado da thread, em 20 de maio, e que pelo menos outros dois usuários confirmaram ("o processo peopled agora está em 0% de consumo de CPU," escreveu um em 26 de junho).

Passo 1: conceda ao Terminal Acesso Total ao Disco

Ajustes do Sistema > Privacidade e Segurança > Acesso Total ao Disco, adicione o Terminal e ative-o. Sem isso, todo comando abaixo falha com "Operation not permitted" — que, por sinal, é o mesmo erro que o peopled está enfrentando. Reinicie o Terminal depois de conceder o acesso.

Passo 2: examine a pasta

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

A flag @ mostra atributos estendidos. O que você procura é com.apple.quarantine na pasta ou nos arquivos CallHistory.storedata dentro dela. Quarentena é o sinalizador que o macOS coloca em arquivos baixados; ele não tem nada que fazer em um banco de dados do sistema, e como ele chega ali não é sabido — uma restauração de backup e uma migração de outro Mac são as duas rotas plausíveis.

Passo 3: remova-o

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

-d apaga o atributo, -r percorre recursivamente a pasta.

Passo 4: reinicie os daemons

sudo killall -9 peopled CallHistorySyncHelper

Ambos serão relançados sob demanda. Observe o Monitor de Atividade por alguns minutos.

Se o sinalizador voltar

Um usuário na thread relatou em 17 de julho que a correção funcionou e o sinalizador de quarentena "reapareceu" durante a noite. Se isso acontecer com você, algo está recolocando a pasta em quarentena, e os candidatos são uma ferramenta de backup ou sincronização que a trata como dado novo. Verifique o que roda durante a noite. Alternativamente, e de forma mais direta, a abordagem de outro usuário foi excluir o banco de dados e deixar o macOS recriá-lo:

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

Você perde a cópia do histórico de chamadas do Mac. Ele é repopulado a partir do iPhone via Continuidade. Isso é uma medida mais drástica do que remover um atributo, e nós tentaríamos o atributo primeiro.

Correção 3: alterne os Contatos do iCloud

Ajustes do Sistema > [seu nome] > iCloud > Salvo no iCloud > Contatos, desative. Espere um minuto, observe a CPU. Se ela cair, reative e veja se permanece baixa.

Isso funciona para um subconjunto de usuários e é o conselho padrão nas threads mais antigas da mesma família de problemas, remontando a anos atrás. Também tem um modo de falha que um usuário encontrou em 11 de maio: o alternador simplesmente não desativava. Se isso acontecer, saia da conta do iCloud por completo (mantendo uma cópia dos dados quando solicitado), reinicie, entre novamente. Note que o relator do V2EX com a variante do accountsd tentou exatamente isso, e a CPU voltou imediatamente após entrar na conta.

Se for o contactsd e você tiver uma conta Exchange ou Google

Esse é anterior ao Tahoe e tem um mecanismo mais claro.

O contactsd é o daemon do framework Contacts: ele é dono do banco de dados da agenda e o reconcilia com toda conta que sincroniza contatos. Ele também faz manutenção em um cronograma — seu job do launchd registra uma tarefa diária validate-cache que roda apenas na energia externa quando você está inativo, e uma atividade repetida accounts.cleanup. CPU breve e ocasional do contactsd é normal.

O que não é normal é um pico a cada minuto ou algo assim. Um desenvolvedor documentou exatamente isso nos Fóruns de Desenvolvedores da Apple em dezembro de 2025: em um M1 Max no Tahoe 26.1, uma conta Office 365 com Contatos ativado levou o AddressBookManager a 81% e o contactsd a 22–59% em um padrão repetido a cada 60–90 segundos — mesmo com a pasta de contatos do Exchange esvaziada no servidor, e reproduzível em uma instalação limpa. A mesma conta e os mesmos dados não fizeram isso em um Mac com M4 nem no iOS. Ninguém da Apple respondeu.

A solução dele é a que funciona: remover a conta Exchange em Ajustes do Sistema > Contas de Internet, e, se precisar dela, usar o Outlook, que não passa pelo framework Contacts. Um relato de fevereiro no fórum da comunidade com o contactsd em um MacBook Pro 2024 no 26.3 recebeu um conselho equivalente — parar de sincronizar contatos do Exchange e do Google e testar — e se você tiver tanto o iCloud quanto uma conta Google sincronizando contatos, tente remover o Google primeiro.

A variante do accountsd

Os relatos mais graves — accountsd em 180% com contactsd e itunescloudd a reboque, em um MacBook Air M5 no 26.5.2, descrito no V2EX em julho — não têm uma correção confirmada. O relator observou que o problema começava no mesmo horário toda manhã, o que aponta para uma tarefa agendada em vez de um evento de widget. Sair e entrar novamente na conta não ajudou.

O que podemos acrescentar: o accountsd é o daemon do framework Accounts e é invocado sempre que algo precisa de uma credencial para uma conta conectada, e o itunescloudd é o daemon da biblioteca iTunes Cloud (Apple Music / Store). Os três ao mesmo tempo significam que algo está pedindo credenciais de conta repetidamente e falhando. Se você tem essa variante, as correções acima ainda valem a pena tentar em ordem, e se nenhuma delas funcionar, vale verificar se uma única conta — um login antigo do Google ou Exchange, uma senha específica de aplicativo expirada — está falhando na autenticação em Ajustes do Sistema > Contas de Internet. Remova qualquer coisa que mostre um distintivo de aviso.

Por que o Tahoe, e por que um widget

Widgets existem no Mac há anos, então é justo perguntar por que isso começou com o 26.4. Duas coisas mudaram juntas.

A primeira é onde os widgets vivem. O Tahoe colocou widgets na Central de Controle ao lado da área de trabalho e da Central de Notificações, e um widget de Contatos na Central de Controle é atualizado em uma cadência diferente de um que fica na área de trabalho — os próprios modelos de log do daemon distinguem uma passagem diária de "sugerir widgets" ("Last widget suggestion date is older 24 hours") de atualizações disparadas por evento ("Event triggered widget refresh"). Mais superfícies, mais solicitações de atualização, mais chances de uma que falha ser tentada de novo.

A segunda é que o tratamento de erros do daemon parece tentar de novo em vez de recuar. Essa é a nossa inferência a partir do comportamento, não algo que possamos ler no binário, e é o bug real: uma leitura negada deveria ser registrada uma vez e a atualização abandonada até o próximo evento genuíno. Em vez disso, ela é tentada de novo, e os eventos continuam chegando.

Nenhuma dessas duas coisas é algo que você pode mudar. O que você pode mudar é se o widget existe e se a leitura é negada, que é o que as três correções fazem.

Depois de corrigido

Algumas coisas mantêm o problema resolvido.

Deixe o Acesso Total ao Disco do Terminal como está se você usou a Correção 2, ou revogue-o deliberadamente — qualquer uma das opções serve, mas saiba qual delas você escolheu, porque Terminal com Acesso Total ao Disco é uma concessão ampla.

Evite a galeria de widgets por um tempo. O relato de 31 de julho na thread é específico: abri-la — sem adicionar nada — reiniciou o loop. Se você quiser adicionar outros widgets, faça isso e depois confira o Monitor de Atividade em seguida.

Depois da próxima atualização do macOS, verifique de novo. Atualizações pontuais já readicionaram itens padrão da Central de Controle para alguns usuários, e um widget de Contatos silenciosamente voltando é o motivo mais provável de o problema retornar.

Registre o relato. Feedback Assistant, categoria macOS, anexe um sysdiagnose feito enquanto a CPU está alta (sudo sysdiagnose pelo Terminal, ou Shift-Control-Option-Command-Ponto), e cole a linha de negação do sandbox. Cinco meses de threads no fórum não moveram isso; algumas centenas de relatos de Feedback com a mesma linha de log talvez consigam.

Já está corrigido?

Não, pelo que se pode dizer. Verificamos as notas de atualização da Apple para o Tahoe: o 26.4.1 "traz correções de bugs," o 26.5 "inclui melhorias, correções de bugs e atualizações de segurança," o 26.6 otimiza o índice do Spotlight, e o 26.6.1 e o 26.6.2 são lançamentos de segurança. Nenhum menciona Contatos, widgets ou CPU. Na thread da comunidade, os relatos continuam no 26.5 ("O problema ainda existe no Tahoe 26.5. A Apple precisa corrigir isso o quanto antes," em 15 de maio) e seguem até julho. Não vimos relato algum, nem a favor nem contra, para o 26.6.2, lançado em 17 de agosto.

Se você está na beta do macOS 27 e viu ou não viu esse problema, o resumo de problemas conhecidos da beta é onde acompanhamos isso.

O que não vale a pena tentar

Redefinir a NVRAM ou o SMC. Nenhum dos dois tem qualquer relação com as permissões de arquivo de um daemon em espaço de usuário. Pule.

tccutil reset All. Um usuário tentou; não ajudou, e isso remove toda permissão de privacidade de todo aplicativo no Mac, o que depois te faz gastar uma tarde reconcedendo tudo. Não há motivo para achar que o TCC é a camada responsável — a negação nos logs é do sandbox, não do TCC.

Modo de Segurança. Reiniciar em Modo de Segurança e voltar limpa alguns caches e deu alívio temporário para alguns usuários. É um reinício com passos extras e não resolve a causa.

Desativar o peopled com launchctl. Você pode usar launchctl disable no agente, e ele vai parar de consumir CPU porque vai parar de rodar. Isso também vai interromper o widget de Contatos, as sugestões de pessoas, a infraestrutura de "pedir para comprar" do Tempo de Uso e o que mais depender dele, e em um Mac com proteção de integridade do sistema, a mudança pode não sobreviver a uma atualização. Não recomendado, exceto como diagnóstico de último recurso.

Solução de problemas comuns

O Monitor de Atividade mostra vinte cópias de contactsd

Vimos isso nós mesmos enquanto escrevíamos: uma explosão de vinte processos contactsd com PIDs consecutivos, todos filhos do launchd, todos a 0% de CPU, desaparecendo em menos de um minuto. Isso é o launchd criando instâncias por cliente sob demanda, e não é o bug. O bug é um único processo em CPU alta que permanece assim.

O widget de Contatos sumiu, mas o peopled ainda está em 80%

Verifique os três locais — área de trabalho, Central de Notificações, Central de Controle — e depois passe para a Correção 2. Se você nunca teve um widget de Contatos, vá direto para a Correção 2.

xattr diz "No such xattr: com.apple.quarantine"

A pasta não está em quarentena, então esse não é o seu gatilho. Tente a Correção 3, e verifique se você tem uma conta Exchange ou Google sincronizando contatos.

ls no CallHistoryDB diz "Operation not permitted" mesmo com sudo

sudo não contorna o TCC. O próprio Terminal precisa de Acesso Total ao Disco, concedido nos Ajustes do Sistema, e depois relançado.

Voltou depois de uma atualização do macOS

Atualizações podem readicionar o widget ao layout padrão da Central de Controle. Verifique os três locais novamente.

Perguntas frequentes

O peopled é malware?

Não. É um daemon assinado pela Apple em /System/Library/PrivateFrameworks/People.framework/peopled, no volume de sistema selado. Um processo com esse nome rodando de qualquer outro lugar valeria a pena investigar; este é da Apple.

Posso simplesmente encerrá-lo?

sudo killall peopled o interrompe até o próximo evento despertá-lo, o que em um Mac movimentado leva segundos. É útil como diagnóstico — se a CPU permanece baixa depois de encerrado, o gatilho sumiu — não como correção.

Remover o widget faz perder alguma coisa?

Só o widget. Contatos, histórico de chamadas e sugestões no Spotlight e no Mensagens continuam funcionando normalmente; o peopled ainda roda quando necessário. Ele só deixa de ser solicitado a atualizar algo que não consegue atualizar.

Por que a pasta CallHistoryDB precisa de Acesso Total ao Disco para ser lida?

Ela contém seu registro de chamadas, que o macOS trata como dado pessoal sensível e protege com o TCC, assim como Mensagens e Mail. Essa proteção é o motivo pelo qual o Terminal precisa da concessão, e também é o motivo pelo qual um sinalizador de quarentena inesperado nela é tão disruptivo: o daemon tem um único caminho estreito e isolado até os dados, e qualquer coisa que bloqueie esse caminho o bloqueia por completo.

O macOS 27 vai corrigir isso?

Desconhecido. A Apple não reconheceu o problema, e não há nada nas notas de versão da beta sobre isso. Se o mecanismo for o que as evidências sugerem, a correção é pequena — falhar uma vez e parar de tentar de novo — e ela poderia chegar em qualquer atualização pontual sem ser mencionada.

Conclusão

Um Mac que roda quente sem fazer nada quase sempre tem um processo em loop, e o loop quase sempre tem uma causa banal. Neste caso, é um daemon cujo trabalho é manter um widget atualizado, que é despertado por toda chamada e mensagem, e que não consegue ler o único banco de dados de que precisa. Remova o widget e as solicitações param; corrija as permissões da pasta e as leituras funcionam. Qualquer uma das duas quebra o loop.

Se você tem o peopled no topo do Monitor de Atividade, percorra as três correções em ordem e reinicie entre elas. Se for o contactsd com uma conta Exchange ou Google, remova a conta. E se forem os três com o accountsd na frente, tente tudo acima, remova qualquer conta que mostre um aviso e — porque a Apple está em silêncio sobre isso há cinco meses — registre o relato de Feedback, com a linha de log do sandbox, que talvez finalmente resolva isso de vez.

Leitura relacionada: Mac quente e com a bateria descarregando após o macOS 26.6, CPU do WindowServer no 26.5 com o Liquid Glass, o app Contatos não funcionando no Tahoe, Monitor de Atividade do zero, e personalizando widgets no Tahoe.