O Que Está Mantendo Seu Mac Acordado? Veja Como Descobrir

Como funcionam as assertions de energia do macOS

O macOS não entra em repouso só porque um cronômetro chegou a zero. Antes de escurecer a tela ou desligar o disco, o kernel verifica se algum processo em execução está segurando uma assertion de energia — uma solicitação registrada através do framework IOKit de gerenciamento de energia que avisa ao sistema que ele precisa continuar acordado. O macOS respeita essa solicitação até que o processo a libere ou termine.

Dois tipos de assertion explicam a maior parte do comportamento de repouso. PreventUserIdleSystemSleep impede o Mac de entrar em repouso por completo — disco, tela, tudo. PreventUserIdleDisplaySleep mantém só a tela acesa e deixa o resto do sistema dormir se quiser. Um gerenciador de downloads, um player de vídeo, o caffeinate rodando no Terminal, ou um app para manter o Mac acordado como o LidRun podem segurar qualquer um dos dois tipos, por motivos diferentes.

Assertions não são um bug — são um recurso projetado assim de propósito, e o mesmo mecanismo corta dos dois lados. A trava que mantém um Mac acordado durante uma rodada de IA a noite inteira é exatamente o mesmo mecanismo que uma aba de navegador esquecida usa para mantê-lo acordado depois que o vídeo já parou de tocar. O objetivo não é desconfiar de toda assertion; é saber quais você pediu e quais apareceram sem convite.

Usando o Monitor de Atividade para encontrar a causa

Abra o Monitor de Atividade em Aplicativos → Utilitários, ou encontre-o pelo Spotlight. Clique na aba Energia. A coluna Impede Repouso mostra Sim ou Não para cada processo que o sistema está monitorando — clique no cabeçalho da coluna para ordenar as assertions ativas no topo.

Surpresas comuns nessa lista: uma aba de navegador com um vídeo pausado, um cliente de sincronização na nuvem no meio de um upload, um backup do Time Machine ainda rodando em segundo plano, um app de podcast, ou uma chamada de vídeo que ficou aberta depois que você saiu da reunião. Clique com o botão direito num item suspeito e escolha Inspecionar Processo para ver o caminho completo do binário e o processo pai — isso costuma resolver a dúvida.

O Monitor de Atividade é uma boa primeira checagem, mas tem pontos cegos. Ferramentas de CLI e daemons em segundo plano — incluindo o caffeinate iniciado pelo Terminal — às vezes aparecem sob um nome genérico, ou simplesmente não aparecem na lista. Para esses casos, o comando de Terminal a seguir dá o quadro completo.

Lendo o pmset -g assertions no Terminal

Abra o Terminal e rode pmset -g assertions. A saída lista todas as assertions de energia ativas no sistema: o tipo, o nome legível que o app deu a ela, e o ID do processo que a registrou. Um bloco de resumo no topo as separa em Listed (ativas no momento) e Timed Out (o prazo estourou, mas o app nunca chamou o release).

Uma assertion com Timed Out ainda pode bloquear o repouso — o processo definiu um prazo, o prazo passou, mas a trava em si nunca foi liberada. Se um PID na saída parecer desconhecido, cruze a informação com ps aux | grep, seguido daquele PID, para confirmar a qual processo ele pertence. Algumas assertions têm um timeout explícito; outras são indefinidas — uma PreventUserIdleSystemSleep indefinida, segurada por um agente em segundo plano travado ou que já deu crash, mantém o Mac acordado sem causa aparente, e é a primeira coisa que vale a pena checar se a máquina está ligada muito mais tempo do que o esperado.

O pmset -g assertions só mostra o que está ativo agora — ele não guarda histórico. Dois comandos relacionados cobrem essas lacunas. O pmset -g puro (sem a flag assertions) inclui uma linha SleepDisabled — uma configuração diferente, global, que algumas ferramentas, e o próprio modo Closed-Lid do LidRun, ativam com pmset -a disablesleep em vez de registrar uma assertion normal (mais sobre isso na próxima seção). E o pmset -g log imprime uma linha do tempo histórica de eventos de repouso, despertar e assertions, útil se você quiser saber o que manteve o Mac acordado durante a noite, e não agora.

Para interromper uma assertion de CLI como a do caffeinate, encontre o PID dela na saída do pmset e rode kill seguido desse PID. Fechar um app também libera as assertions dele imediatamente — assertions comuns estão atreladas ao processo, então o macOS as limpa no instante em que o processo termina, sem precisar de um passo extra de limpeza. Se uma assertion não mostrar um dono claro, ou o processo dela já tiver dado crash, reiniciar o Mac limpa todas as travas pendentes.

Quando o pmset -g assertions não retorna nada

Às vezes o pmset -g assertions não retorna nada, mesmo assim o Mac parece nunca desligar de verdade — a ventoinha acelera e desacelera, ou a tela pisca e acende sem nenhum app à vista. Normalmente isso não é uma assertion escondida; é um dark wake agendado. O macOS periodicamente acorda por um instante para tarefas de rede — sincronização do iCloud, Find My, Handoff e Power Nap — mesmo sem nada segurando uma trava, e volta a dormir sozinho segundos depois.

Se você quiser descartar essa hipótese, vá em Ajustes do Sistema → Bateria → Opções e desative Ativar para acesso à rede. Isso não vai parar uma assertion de verdade — se algo estiver de fato registrando PreventUserIdleSystemSleep, esse ajuste não muda nada — mas remove o ruído de fundo, o que torna uma nova checagem de pmset -g assertions mais fácil de ler.

Esse também é o momento de checar o pmset -g puro em busca de uma linha SleepDisabled: 1, descrita acima. Ela não aparece em pmset -g assertions porque não é uma assertion — é uma configuração de sistema permanente, na maioria das vezes deixada ligada por um pmset -a disablesleep disparado por um script, uma ferramenta de terceiros, ou um app (incluindo o modo Closed-Lid do LidRun) que deu crash antes de conseguir se desligar sozinho.

Assertions intencionais vs. indesejadas

Nem toda assertion precisa ser removida. Se você está rodando uma sessão longa do Claude Code, um job de modelo local, ou um agente do Cursor durante a noite, é esperado que algo esteja segurando essa assertion — matá-la mataria seu trabalho junto. A pergunta real não é só 'por que meu Mac está acordado?', mas 'eu pedi por isso?'

Um gerenciador de downloads segurando a prevenção de repouso até uma transferência terminar está fazendo o trabalho dele. Um player de vídeo segurando isso depois que você já fechou a janela, não. Uma ferramenta que você configurou de propósito — LidRun, um caffeinate -i rodado manualmente — é intencional. Uma aba de navegador com um vídeo pausado que você esqueceu não é. A diferença está no consentimento, não no mecanismo.

Se você chegou à conclusão de 'sim, eu quero isso', já existem opções gratuitas e nativas. O caffeinate -i, rodado pelo Terminal, registra a mesma assertion PreventUserIdleSystemSleep descrita antes, pelo tempo que o comando ficar rodando — adicione -t 3600 para um teto de uma hora. Ele está atrelado ao processo, então encerrar o comando ou fechar a janela do Terminal libera a assertion automaticamente. O caffeinate não ajuda com a tampa fechada, porém — uma assertion de idle-sleep não alcança o repouso por clamshell. A única alavanca gratuita para isso é sudo pmset -a disablesleep 1, e ela se comporta diferente de propósito: é uma configuração global e permanente, não atrelada a um processo, então sobrevive mesmo que o app que a ativou dê crash, e continua ligada até que algo rode explicitamente pmset -a disablesleep 0 ou o Mac reinicie. Apps de barra de menu como Amphetamine, KeepingYouAwake, Lungo e Caffeine embrulham o mesmo mecanismo de base num interruptor de um clique, o que é uma escolha perfeitamente boa se um controle manual é tudo que você precisa. De um jeito ou de outro, continua sendo a mesma assertion ou a mesma flag disablesleep por baixo dos panos — e é exatamente por isso que vale a pena conhecer o pmset -g assertions, não importa qual ferramenta registrou a trava. A comparação entre LidRun e caffeinate detalha toda a diferença de custo e recursos.

Para uma trava que você quer manter, mas manter com segurança, o que importa são as proteções: uma parada automática antes que a bateria chegue perigosamente baixa, atenção ao estado térmico para que um Mac quente não fique preso acordado indefinidamente, e limitar a assertion a uma única tarefa para que ela se libere no instante em que a tarefa termina, em vez de depender de você lembrar. O Auto Mode do LidRun cuida desse escopo: aponte para um nome de processo — uma sessão do Claude Code, um build, um job de render — e ele segura a assertion só enquanto esse processo está rodando, liberando-a no instante em que o processo termina. Agente rodando, mantém acordado; agente terminou, libera — esse é todo o design, não uma trava cega deixada ligada até alguém lembrar de desligar. O guia manter acordado automaticamente, só enquanto trabalha cobre esse padrão em detalhe. Na bateria, o LidRun também se desliga sozinho abaixo de um limite — 20% por padrão, ajustável entre 15% e 50% — independente do que ainda estiver rodando, e sai do modo Closed-Lid assim que o sistema reporta pressão térmica crítica (com um aviso no estágio sério, antes disso), porque uma tampa fechada bloqueia o principal caminho de resfriamento do Mac, e nenhuma automação deveria mantê-la fechada enquanto ele está superaquecendo.

Quando o culpado é indesejado, fechar o app resolve na hora. Se o mesmo processo continuar reaparecendo depois de um reinício, verifique Ajustes do Sistema → Geral → Itens de Login e Itens em Segundo Plano à procura de agentes configurados para iniciar automaticamente. Remover ou desativar o item de login interrompe o ciclo na origem.