LidRun CLI: mantenha um Mac acordado pelo terminal

O que o CLI lidrun realmente é

O lidrun não é um programa separado com lógica própria — é um pequeno script wrapper, instalado em ~/.local/bin/lidrun ou /usr/local/bin/lidrun, que roda o mesmo binário do LidRun.app que você já tem, só que chamado com uma flag --cli em vez de aberto com duplo clique. Mover o app depois, de Downloads para Applications, não quebra o wrapper, porque ele é gerado apontando para onde o pacote do app realmente está no momento da instalação.

Por baixo do capô, ele se divide em dois comportamentos genuinamente diferentes, e confundir os dois é a forma mais fácil de interpretar mal o que um comando está fazendo. lidrun -- <command> é autocontido: abre sua própria power assertion de vida curta para o processo filho e a libera no instante em que esse processo termina, sem precisar do app LidRun aberto em nenhum momento. Todo o resto — status, start, stop, autowatch, watch, unwatch, patterns, timer, notify — depende do daemon: abre uma conexão local por Unix socket com o app em execução e pede para ele mudar de estado. Se o app não estiver aberto, esses comandos falham na hora com um erro, não ficam silenciosamente sem fazer nada.

Essa divisão importa para o que "governado por segurança" realmente significa mais adiante neste texto — não é a mesma coisa para todo comando, e fingir o contrário é o tipo de afirmação que só se sustenta até o dia em que o Mac de alguém descarrega a bateria dentro de uma mochila.

O jeito gratuito: caffeinate e pmset

Antes de recorrer a qualquer ferramenta, o macOS já vem com duas formas de fazer isso pelo terminal, e vale ser direto sobre elas — são recursos genuinamente capazes, não gambiarras. caffeinate -i your-command, ou caffeinate -i rodando sozinho numa aba reserva, mantém uma assertion de idle-sleep enquanto o utilitário estiver ativo. Sem instalar nada, sem precisar confiar em nada novo, e faz parte do macOS há bem mais de uma década — muita gente que já fez isso antes tem o comando na ponta dos dedos.

Especificamente para uso com a tampa fechada, pmset disablesleep 1 diz ao macOS para ignorar os gatilhos de suspensão em todo o sistema, incluindo o sensor da tampa — exatamente o mecanismo que o próprio modo Closed-Lid do LidRun usa por baixo, e é por isso que o LidRun toma o cuidado de sempre parear um disablesleep 1 com um disablesleep 0 correspondente quando uma sessão clamshell termina: ao parar, ao fechar o app, e de novo ao abrir, caso a última execução não tenha limpado direito. Rodado manualmente, é um one-liner genuíno para builds com a tampa fechada, sem instalar nada.

Para um único comando que você está acompanhando na frente da tela, caffeinate -i npm run build é, com toda honestidade, tão bom quanto qualquer coisa aqui, LidRun incluído.

Onde caffeinate e pmset chegam ao limite

A lacuna aparece quando ninguém mais está de olho na sessão. Nenhuma das duas ferramentas sabe a porcentagem de bateria nem a temperatura do Mac — elas seguram exatamente o que foram mandadas segurar, pelo tempo que foram mandadas segurar, e ponto final.

disablesleep é a versão mais afiada desse risco, porque é uma configuração global, não restrita a uma aba do terminal. Se o script que rodou pmset disablesleep 1 travar, for encerrado antes de chegar ao 0 correspondente, ou uma sessão SSH cair no meio do processo, o Mac fica se recusando a dormir — tampa fechada, sem ninguém por perto, não importa o quanto esteja esquentando — até alguém perceber e limpar isso manualmente. É exatamente por causa desse tipo de falha que o uso do disablesleep pelo próprio LidRun é pareado defensivamente em três lugares separados, não só em um.

A versão do caffeinate desse risco é mais discreta, mas igualmente real: um caffeinate -i rodando em segundo plano desde três deploys atrás, ainda vivo numa aba de terminal que ninguém fechou, drenando a bateria de um notebook dentro de uma mochila sem que nada esteja de olho. Nenhuma das duas ferramentas está errada em funcionar assim — o caffeinate faz um trabalho, de forma limpa, por design. Só não é um piso de bateria ou temperatura, e nunca tentou ser.

Instalando o CLI lidrun

O CLI não é um download separado. Abra o LidRun, vá em Settings, depois Command Line, e clique em Install lidrun CLI… — isso grava o script wrapper descrito acima e oferece uma escolha de escopo.

Instalar em ~/.local/bin/lidrun não pede senha de administrador em nenhum momento; pode ser que você precise adicionar ~/.local/bin ao seu PATH uma única vez, caso ainda não esteja lá — o próprio diálogo do instalador avisa isso abertamente. Instalar em /usr/local/bin/lidrun coloca o lidrun no PATH de todo shell sem essa etapa extra, mas pede uma senha de administrador uma única vez, já que escrever ali exige root.

lidrun --version confirma qual build está realmente em execução — ele lê o mesmo número de versão do próprio app, então o CLI não corre o risco de ficar silenciosamente dessincronizado da interface gráfica — e lidrun help imprime a lista completa de comandos sem sair do terminal.

Todos os comandos que o CLI lidrun realmente tem

lidrun status vale a pena ser o primeiro comando, e o mais usado. A frio, ele imprime Mode: Awake Off, Assertion: inactive, Clamshell: off; rode de novo depois de lidrun start e o Mode aparece como Awake On com Assertion active — ele também acrescenta linhas de Battery e Thermal sempre que o Mac tem bateria e um estado térmico que valha a pena mostrar. lidrun start e lidrun stop são o par explícito de ligar/desligar, e lidrun -- <command> é o wrapper, que mantém o keep-awake por exatamente o tempo de vida daquele processo e devolve o código de saída real dele quando termina — confira o $? depois e você estará lendo o resultado do próprio comando encapsulado, não do lidrun.

Uma correção que vale a pena fazer sem rodeios: não existe um lidrun on, lidrun off ou lidrun toggle isolado. Essas palavras só existem como argumento de autowatch — lidrun autowatch on, off ou toggle liga ou desliga o Auto Mode, o modo que mantém o keep-awake só enquanto um processo monitorado está de fato em execução, e solta sozinho assim que deixa de estar. lidrun watch <pattern> e lidrun unwatch <pattern> adicionam ou removem um nome dessa lista de monitoramento, e lidrun patterns lista o que está nela no momento.

Mais dois comandos completam a lista: lidrun timer 3600 mantém o keep-awake por um número fixo de segundos e se libera sozinho quando o tempo acaba, e lidrun notify "Build done" "exit 0" dispara uma notificação local e push pelo mesmo canal que os próprios alertas do app usam — uma última linha razoável para fechar um script encapsulado.

Dois padrões de script, e uma pegadinha de aspas

Para um script inteiro com mais de uma etapa, coloque-o entre colchetes: lidrun start no topo, lidrun stop no final, e tudo o mais rodando no meio exatamente como rodaria sem o LidRun envolvido. Como os dois são comandos de daemon que retornam na hora, não importa se o script está num terminal em primeiro plano ou rodando headless via SSH — o app é quem mantém o estado de verdade.

O risco real desse encapsulamento é o mesmo do caffeinate e do disablesleep: se uma etapa anterior falhar e o script sair antes de chegar em lidrun stop, o Mac fica preso numa retenção sempre ativa que ninguém vai lembrar de liberar. O ajuste padrão é uma trap de uma linha no topo do script — trap 'lidrun stop' EXIT — que roda lidrun stop não importa como o script termine, travamento incluído.

Para uma etapa única, a forma wrapper dispensa a trap por completo: lidrun -- ./build.sh mantém a assertion pelo tempo de vida exato daquele processo e a libera no instante em que ele termina, com sucesso ou falha — o mesmo formato de caffeinate ./build.sh.

Um detalhe que vale a pena conhecer antes que ele te pegue de surpresa: lidrun -- roda os argumentos unidos através de um login shell de verdade, então operadores de shell dentro de uma única string entre aspas funcionam como esperado. lidrun -- "npm run build && npm test" mantém um único keep-awake ao longo das duas etapas. Tire as aspas e escreva lidrun -- npm run build && npm test em vez disso, e o seu shell externo interpreta o && primeiro — só npm run build é passado para o lidrun, e npm test roda depois, sem proteção nenhuma, quando o lidrun já tiver terminado. Como roda através de um login shell, entradas de PATH do Homebrew, pyenv ou nvm também são resolvidas do mesmo jeito que num terminal interativo, o que evita uma pegadinha comum de ferramentas que chamam o shell diretamente.

O que as proteções de segurança do LidRun realmente cobrem numa sessão de CLI

Essa é a parte que vale a pena tratar com precisão, porque a resposta honesta depende de qual comando você usou, não do "CLI" como se fosse uma coisa só. A proteção de bateria e temperatura do LidRun vive no rastreamento de estado do próprio app em execução, não numa power assertion crua por si só — então o que uma sessão lidrun recebe depende de o app estar monitorando aquela assertion específica ou não.

lidrun start, timer e autowatch mantêm uma assertion que o app monitora ativamente. Por padrão, se a bateria cair abaixo de 20% enquanto um desses estiver ativo, o app libera a retenção sozinho — a mesma coisa que lidrun stop faria — para que o Mac possa dormir normalmente antes que a situação fique urgente. É o mesmo piso suave que o toggle Always On da barra de menu recebe, porque é o mesmo estado monitorado por baixo.

lidrun -- <command> não recebe esse piso suave, porque a assertion dele vive no próprio processo de vida curta do CLI, fora de qualquer coisa que o app esteja monitorando — não existe estado para o app liberar antecipadamente. Se o app LidRun estiver aberto ao mesmo tempo, o que é comum já que é um utilitário de barra de menu, o piso de emergência rígido dele ainda se aplica em todo o sistema: perto de 4% de bateria por padrão (configurável entre 4% e 8%), o LidRun chama pmset sleepnow diretamente, o que força todo o Mac a dormir independentemente de quem estiver segurando uma assertion, incluindo a do próprio comando encapsulado. Se o app não estiver rodando de jeito nenhum, nada interfere, e lidrun -- <command> se comporta exatamente como uma retenção nua de caffeinate -i <command>: sem piso de bateria, sem checagem de temperatura, só prevenção de idle-sleep enquanto o processo estiver rodando.

Na prática, essa é uma troca perfeitamente razoável para um build ou teste que você está acompanhando de perto — nesse caso, você é a checagem de segurança. Para uma execução noturna genuinamente sem supervisão, onde o piso de bateria precisa valer do início ao fim, lidrun start pareado com lidrun stop, ou o Auto Mode, com o app aberto, é a versão que fica sendo monitorada continuamente, não apenas amparada caso algo fique crítico.

CI em notebook, execuções sem supervisão, e onde o CLI se encaixa perto de tudo mais

O motivo real para recorrer a qualquer uma dessas ferramentas é um runner self-hosted ou um job noturno num Mac que está de fato sobre uma mesa em algum lugar — o tipo de máquina sem supervisão que entra em sleep por inatividade sozinha, diferente de uma VM de CI efêmera na nuvem. Encapsular o job com lidrun -- ./nightly.sh, ou colocá-lo entre start e stop, evita que o Mac durma por inatividade no meio da execução.

O CLI é uma costura num pequeno conjunto de ferramentas que se sobrepõem de propósito. O Auto Mode (lidrun autowatch on) mantém o Mac acordado só enquanto um processo monitorado está realmente em execução, sem nada para lembrar de equilibrar depois. A tela Run Command da interface gráfica faz o mesmo trabalho de lidrun -- <command>, só que a partir de uma janela em vez do terminal, e mostra o código de saída e a duração do que rodou quando termina — a mesma informação que o $? dá ao CLI. Qual usar depende, na maior parte das vezes, de onde o job começa: um script recorre ao CLI, uma execução manual e pontual recorre à interface gráfica.

Se o fluxo de trabalho vive inteiramente num toggle da barra de menu em vez de um script, Amphetamine, KeepingYouAwake, Lungo e Caffeine são ferramentas estabelecidas e genuinamente capazes, com suas próprias regras de gatilho — abertura de app, rede Wi-Fi, horário do dia. Elas não foram construídas primariamente em torno de um fluxo de terminal roteirizável e ciente de código de saída, do jeito que lidrun -- e caffeinate são, então, se o job começa num script ou num Makefile em vez de num clique, as ferramentas de CLI são a escolha mais adequada para esse trabalho específico.

As mesmas ressalvas valem aqui como em qualquer outro lugar: uma superfície rígida e ventilada, além de energia na tomada, são a configuração certa para qualquer coisa que rode por muito tempo, e o CLI ajuda a reduzir o atrito de manter um Mac acordado direto do terminal. Isso não substitui checar de fato a máquina que você pediu para rodar sem supervisão durante a noite.