Execute um comando longo e deixe o Mac dormir quando ele terminar

O problema do keep-awake manual

O ritual de sempre são dois passos que você precisa lembrar na ordem certa: ligar o keep-awake, começar o job e, depois, torcer para lembrar de desligar o keep-awake quando ele acabar. É o segundo passo que costuma escapar.

Esqueça isso e o Mac fica acordado por horas depois que um job de quarenta minutos já terminou — gastando bateria, ou simplesmente sem descansar em cima da mesa. Desligue cedo demais e você corta o job pela metade. Nenhum dos dois é o que você realmente queria, que era mais simples do que os controles permitem: manter o Mac acordado enquanto aquele comando roda, e só. Amarrar o estado de keep-awake ao tempo de vida do próprio trabalho, não a um interruptor que alguém precisa lembrar de virar.

O jeito gratuito e nativo: caffeinate

Antes de sair instalando qualquer app, vale saber que o macOS já faz o truque principal de graça. O caffeinate vem instalado em todo Mac e, segundo o próprio man page: "If a utility is specified, caffeinate creates the assertions on the utility's behalf, and those assertions will persist for the duration of the utility's execution." O próprio exemplo da documentação é exatamente esse padrão: caffeinate -i make cria um processo filho para make, segura uma assertion de idle-sleep enquanto ele roda e solta quando termina. Troque pelo seu próprio job — caffeinate -i ./run-migrations.sh ou caffeinate -i npm test — e você tem o mesmo keep-awake do tamanho do comando que o LidRun oferece, sem instalar nada.

As flags importam: -i evita o idle sleep (o caso mais comum), -d também mantém a tela ligada, -s evita o system sleep por completo, mas só funciona na tomada, e -m impede que o disco entre em modo de economia. Sem nenhuma flag, um caffeinate your-command puro já evita o idle sleep por padrão. É uma ferramenta genuinamente sólida para um job em primeiro plano que você está acompanhando.

O que o caffeinate não resolve é a tampa fechada. As assertions dele impedem o idle sleep, não o sleep forçado que o macOS dispara no instante em que você fecha fisicamente a tampa de um Mac sem monitor externo conectado. O jeito clássico e gratuito de contornar isso é a configuração clamshell tradicional — monitor externo mais teclado/mouse externos, tampa fechada, e o Mac continua rodando porque o macOS passa a tratá-lo como se estivesse efetivamente acoplado a uma estação. A outra alavanca, a mesma que o Closed-Lid mode do próprio LidRun aciona por baixo dos panos, é o comando não documentado mas bem conhecido sudo pmset disablesleep 1 — uma flag em nível de sistema que bloqueia o sleep por completo até que algo a devolva para 0.

Onde o jeito gratuito para de dar conta

O caffeinate não te conta nada quando o job termina. Não aparece exit code, não aparece duração, não vem notificação nenhuma — você volta a ficar de olho numa aba de terminal, ou escreve seu próprio wrapper tipo caffeinate -i ./job.sh; echo "exit $?" e precisa lembrar de checar depois. Para uma migração de quarenta minutos isso é um incômodo pequeno; para uma exportação que você deixou rodando de madrugada antes de dormir, significa acordar e encontrar uma janela de terminal cheia de texto para rolar, não uma resposta clara.

O caffeinate também não sabe nada sobre sua bateria ou o estado térmico do Mac. Ele segura a assertion às cegas enquanto o processo rodar — que é exatamente o que você pediu, mas isso significa que um job caffeinate -i deixado rodando sem supervisão na bateria durante a noite não tem ninguém de olho no seu limite mínimo de bateria configurado. O pmset disablesleep é ainda mais bruto: precisa de sudo, é em nível de sistema (bloqueia o sleep para tudo, não só para o seu job) e fica travado em 1 até que algo o reverta explicitamente — pule essa etapa e o Mac não vai dormir para nada até você lembrar.

Vale citar com justiça os apps de terceiros que ligam/desligam esse estado — Amphetamine, KeepingYouAwake, Lungo, o Caffeine original — em vez de simplesmente descartá-los. O Amphetamine em particular tem um sistema de gatilhos bem rico: pode ativar ao abrir um app, num horário programado, ou por nível de bateria, o que é mais configurável do que qualquer coisa que o LidRun oferece aqui. KeepingYouAwake e Lungo são toggles de menu bar propositalmente minimalistas; o Caffeine é o clássico de um clique só. O que nenhum deles faz é observar o exit code de um comando específico — eles gerenciam um estado de 'ativo' persistente que você liga e desliga na mão, ou um gatilho sem relação nenhuma com o job realmente ainda estar rodando. É o mesmo problema de esquecer de desligar do início do artigo, só que com um ícone de menu bar mais bonito.

Em vez disso, entregue o comando para o LidRun

O Run & Watch a Command é um recurso Pro que inverte o modelo do caffeinate: em vez de você gerenciar o estado de keep-awake, você entrega o comando para o LidRun e ele cuida disso por você. Por baixo dos panos, ele executa seu comando através do mesmo login shell que o Terminal usa (/bin/zsh -l -c), então as ferramentas do PATH — Homebrew, pyenv, nvm, o que quer que claude ou ollama precisem resolver — funcionam do mesmo jeito que funcionariam se você tivesse digitado o comando você mesmo. Ele mantém o keep-awake durante todo o ciclo de vida do comando e solta no instante em que ele termina, a mesma promessa que o LidRun cumpre em todo o resto do app: comando rodando → mantém acordado, comando terminado ou inseguro → solta.

Enquanto o comando roda, o LidRun captura um trecho contínuo da saída — as últimas 200 linhas, visíveis ao vivo na janela da menu bar — para você não ficar encarando um terminal vazio torcendo para que ainda esteja vivo. É uma visualização ao vivo, não um arquivo de log salvo; se precisar do histórico completo depois, redirecione a saída do próprio comando para um arquivo como faria normalmente. Se você digitar apenas um interpretador sem nada de fato para rodar (python3 sem script), o runner sinaliza isso em vez de fingir que um encerramento em zero segundos foi um job de verdade.

Quando termina, você recebe a parte que mais importa: o exit code e quanto tempo levou, formatado de forma simples (12m 34s, 1h 23m). Você sempre recebe uma notificação local; se tiver configurado um provedor de push — ntfy.sh (grátis) ou Pushover —, ela chega no seu celular também, e no Pro você ainda pode distribuir para Telegram, Discord, Slack ou uma URL de webhook genérica. Se você iniciar uma sessão na bateria, o LidRun avisa de antemão qual é o seu limite de auto-stop configurado (20% por padrão), em vez de deixar você descobrir depois.

Essa também é a diferença honesta de segurança em relação a um caffeinate puro: se a bateria cai abaixo desse limite, ou o Mac entra em pressão térmica crítica, o LidRun não simplesmente solta a assertion em silêncio e torce para dar certo — ele envia ao comando em execução um sinal de terminate de verdade, o mesmo que clicar em Stop. Isso é uma interrupção real, não uma sugestão suave, então é mais protetor do que um wake lock cego, embora um job interrompido alguns minutos antes de terminar sozinho ainda seja uma interrupção, não uma garantia de que a execução seria concluída. E, assim como o caffeinate, isso mantém o Mac acordado durante o idle sleep, não durante uma tampa fisicamente fechada — combine com o Closed-Lid mode (ou um monitor externo) se a tampa for ficar fechada.

A mesma coisa pela linha de comando

Se você vive no terminal, lidrun -- <command> [args...] faz a mesma amarração de ciclo de vida e, diferente do Run & Watch, é gratuito e totalmente autocontido — funciona mesmo se o app LidRun não estiver aberto, porque ele mantém sua própria assertion IOKit de curta duração só para o processo empacotado, soltando-a quando o processo termina. lidrun -- ./run-migrations.sh ou lidrun -- npm test se lê exatamente como digitar o comando direto, porque por baixo dos panos é isso mesmo — mesmo login shell, mesma resolução de PATH. Ctrl-C aborta como em qualquer job em primeiro plano.

Por ser autocontido, o mais honesto é dizer isso claramente: o lidrun -- não checa sua porcentagem de bateria nem o estado térmico por conta própria — esse governor vive no recurso Run & Watch da interface gráfica, atrelado às configurações de segurança normais do app. Na bateria, para um job de horas, isso vale saber antes de deixar rodando em segundo plano e sair de perto; a tomada continua sendo a escolha mais segura de qualquer forma.

Uma pegadinha real que vale conhecer se você quiser encadear mais de um comando sob uma única sessão de keep-awake: coloque tudo entre aspas como um único argumento do shell. lidrun -- 'npm test && npm run build' funciona corretamente — os dois comandos rodam dentro da mesma sessão empacotada. Já envolver isso num shell extra, tipo lidrun -- bash -c 'npm test && npm run build', não funciona: o LidRun rejunta a lista de argumentos com espaços simples antes de rodá-la de novo pelo login shell, o que descarta silenciosamente as aspas internas e pode cortar parte do comando. Aspas em um único argumento é o padrão confiável. De qualquer um dos dois jeitos, o exit code do seu próprio comando volta como o exit code do wrapper, então encaixa direto numa cadeia &&/|| de script ou numa checagem $?, exatamente como rodar o comando direto.

CLI ou runner com interface gráfica — qual escolher

Use a CLI quando você já ia digitar o comando de qualquer jeito, quer colocá-lo num script ou num workflow guiado por terminal, ou não precisa (ou não tem) do Pro. O exit code volta direto para o seu próprio shell, e não há nada para abrir ou configurar.

Use o Run & Watch a Command na interface gráfica quando quiser o auto-stop de bateria/térmico realmente de olho no job — não só segurando uma assertion e torcendo — ou quando quiser uma notificação no celular sem manter uma janela de terminal aberta, ou quando um trecho de saída ao vivo na menu bar for mais confortável do que uma aba de terminal. Isso custa uma licença Pro; o caminho da CLI é o equivalente gratuito para tudo, exceto esse governor de segurança e a distribuição de notificações.

De um jeito ou de outro, o destino é o mesmo: o trabalho termina, o resultado é conhecido, e o Mac fica livre para dormir em vez de ser deixado acordado por um interruptor que ninguém desligou de volta.

Onde isso se encaixa

Pense nos jobs que você inicia e depois vai fazer outra coisa: uma migração de banco de dados longa que você quer confirmar que terminou limpa, uma suíte de testes completa que leva vinte minutos e você prefere não ficar vigiando, uma exportação de dados iniciada antes de dormir que deveria estar pronta de manhã. Para todos esses casos, o relatório no final é metade do valor — saber o exit code e a duração te diz se a migração foi aplicada, se a suíte passou, se a exportação de fato terminou, sem precisar rolar a saída inteira.

Pelo caminho da interface gráfica, ele roda dentro da mesma fronteira de segurança de tudo o mais no app: cruze seu limite de bateria configurado, ou entre em pressão térmica crítica, e o LidRun interrompe o comando de vez, em vez de forçar o hardware a aguentar. O caminho da CLI não tem esse governor embutido, então, para uma execução sem supervisão durante a noite, energia na tomada e uma superfície firme e ventilada continuam sendo a escolha certa independente de qual caminho você usa — isso ajuda a reduzir o risco numa execução longa sem supervisão; não é garantia de que o job sobrevive não importa o que o hardware esteja passando.