O Que Está Deixando Seu Mac Acordado? Aqui Está Como Descobrir

Como as power assertions do macOS funcionam

o macOS não dorme apenas por uma contagem regressiva. Antes de escurecer a tela ou desligar o disco, o kernel verifica se algum processo em execução segura uma power assertion — uma solicitação programática registrada através do framework IOKit power management que diz que a máquina precisa ficar acordada. o macOS honra esse pedido até o processo liberar ou o processo ser encerrado.

Dois tipos de assertions controlam a maioria do comportamento de sono. PreventUserIdleSystemSleep bloqueia o Mac de dormir completamente — disco, display, tudo. PreventUserIdleDisplaySleep mantém a tela acesa mas deixa o resto do sistema dormir se quiser. Um gerenciador de downloads, um player de vídeo, caffeinate rodando do Terminal, ou uma ferramenta como LidRun podem segurá-los, por razões diferentes.

Assertions não são um bug; elas são um recurso projetado. O mesmo mecanismo que mantém a máquina acordada durante uma sessão noturna de IA é o mesmo que uma aba de navegador esquecida usa para manter seu Mac acordado depois que você parou de assistir um vídeo. O objetivo é saber quais assertions você pediu e quais apareceram sem convite.

Usando Activity Monitor para encontrar a causa

Abra Activity Monitor em Applications → Utilities ou procure com Spotlight. Clique na aba Energy. A coluna chamada Preventing Sleep mostra Yes ou No para cada processo que o sistema está monitorando — ordene por ela para empurrar assertions ativas para o topo.

Surpresas comuns nessa lista: uma aba de navegador reproduzindo vídeo pausado, um cliente de sincronização em nuvem no meio de um upload, um app de podcast, ou uma ferramenta de videoconferência que manteve sua sessão aberta depois que você saiu da chamada. Clique com o botão direito em qualquer entrada suspeita e escolha Inspect Process para ver o caminho binário completo e seu processo pai — isso geralmente deixa o culpado óbvio.

Activity Monitor é uma boa primeira passagem, mas tem limites. Ferramentas CLI e daemons de background — incluindo caffeinate lançado do Terminal — podem aparecer sob um nome de processo genérico ou não aparecer em tudo. Para esses, o comando Terminal abaixo dá uma visão mais completa.

Lendo pmset -g assertions no Terminal

Abra Terminal e execute pmset -g assertions. A saída lista cada power assertion ativa no sistema: o tipo de assertion, o nome legível que o app deu, e o ID do processo que a registrou. O bloco de resumo no topo as agrupa em Listed (atualmente ativas) e Timed Out (o timer dispárou mas o app ainda não chamou release).

Uma assertion expirada ainda pode bloquear o sono — o processo a registrou, o relógio marcou, mas o lock nunca foi liberado. Se você ver um PID na saída que parece desconhecido, faça referência cruzada com ps aux | grep seguido pelo número do PID para confirmar o nome do processo.

Para parar uma assertion CLI como caffeinate, encontre seu PID na saída de pmset e execute kill seguido desse PID no Terminal. Para assertions baseadas em app, encerrar o app as libera imediatamente. Se a assertion não mostra um proprietário claro ou o processo já falhou, um reinicialização limpa todos os locks pendentes.

Algumas assertions têm um timeout explícito; outras são indefinidas. Uma PreventUserIdleSystemSleep indefinida segura por um agente de background congelado ou que falhou mantém o Mac acordado sem causa visível. Se sua máquina ficou acordada por um tempo inesperadamente longo, isso é a primeira coisa que vale a pena verificar.

Assertions de wake intencionais vs indesejadas

Nem toda assertion precisa ser removida. Se você está rodando uma longa sessão de Claude Code, um job de modelo local, ou um agent Cursor durante a noite, algo deve estar segurando essa assertion — parar isso mataria seu trabalho. A pergunta certa não é apenas 'por que meu Mac está acordado?' mas 'será que pedi por isso?'

Um gerenciador de downloads segurando prevenção de sono até uma transferência terminar está fazendo a coisa certa. Um player de vídeo segurando isso depois que você fechou a janela não está. Uma ferramenta que você explicitamente configurou — LidRun, caffeinate -i rodado manualmente — é intencional. Uma aba de navegador com um vídeo pausado que você esqueceu não é. A distinção é consentimento, não o mecanismo.

Para holds intencionais de longa duração, guardrails importam: parada automática com bateria baixa, awareness de limiar térmico, e escopo da assertion para um processo específico para que ela seja liberada automaticamente quando o trabalho terminar. O modo process-watch do LidRun trata disso — ele segura a assertion apenas enquanto um processo nomeado está rodando, depois libera sem você ter que lembrar de parar. Esse padrão é coberto em detalhes no guia auto-keep-awake-only-while-working.

Quando o culpado é indesejado, encerrar o app o corrige imediatamente. Se o mesmo processo continuar aparecendo após um reinicialização, verifique System Settings → General → Login Items e Background Items para agentes definidos para iniciar automaticamente. Remover ou desativar o login item para o ciclo na fonte.