Você digita /yolo no Hermes no Telegram e ele responde que o modo YOLO está ligado e que todo comando será auto-aprovado. Você entrega a ele uma cadeia de passos de automação na suposição de que ele simplesmente vai em frente em vez de perguntar. Durante a noite você atualiza o Hermes, o gateway reinicia, e na manhã seguinte você manda outra instrução — e agora ele começa a perguntar, comando a comando, se pode prosseguir. Você vai cavar a config: o YOLO não estava ligado? A resposta dói um pouco: ele foi desligado sem você perceber, e nada avisou. A correção também cria risco na direção oposta, então vale explicitar as duas.

O problema: o switch só existia na memória

Numa plataforma de mensagens, o /yolo antes não mudava mais do que um conjunto em memória dentro de tools.approval. O que significava:

• reiniciar o gateway (hermes update, um crash, o systemd trazendo ele de volta, uma reabertura do Desktop) → a memória limpa → aquele chat volta silenciosamente para aprovações manuais;
• nada na UI diz “o seu YOLO acabou”, então você continua acreditando que ele está ignorando os prompts.

Aí duas coisas acontecem ao mesmo tempo. Você acha que ele está executando sozinho enquanto ele espera você aprovar cada passo, e se a sua automação depende de “nenhuma confirmação humana”, ela trava ali até dar timeout. A redação oficial do relatório é direta: o usuário ainda acreditava que o YOLO estava ligado.

Agora: salvo com a sessão — e só com a sessão

A nova implementação põe a flag na própria entrada de roteamento do chat (SessionEntry.yolo, persistida em gateway_routing ao lado do override do /model). Vale ler as regras uma a uma, porque são elas que decidem qual situação vai te surpreender:

• O /yolo grava a cópia persistida antes de virar a flag ao vivo, e materializa a entrada quando você o liga numa primeira mensagem.
• Todo turno rearma a flag ao vivo a partir da entrada que ele já resolveu — assim o primeiríssimo turno após um restart restaura o estado, em vez de esperar você digitar /yolo de novo.
• A flag é carregada através de compression-tip e de repontos de binding (switch_session).
• O funil de segurança da fronteira de conversa limpa a cópia persistida junto com a em memória: /new, /resume, /branch e auto-reset. A intenção é explícita — um restart nunca pode reviver um bypass que você já descartou.

A documentação agora declara o escopo de forma clara: o /yolo se aplica apenas à sessão em que foi digitado; ele é salvo com a sessão, então sobrevive a um restart — um chat de mensagens o mantém através de restarts do gateway, e a TUI e o app Desktop o mantêm quando você reabre ou retoma a sessão. Numa plataforma de mensagens, /new e /resume iniciam a próxima conversa com as aprovações de volta ligadas.

Conferir o estado da sua sessão é simples:

# estado do YOLO da sessão atual (e se ele foi persistido)
hermes status

# desligue-o E descarte a cópia persistida: inicie uma conversa nova
/new

Já que estamos aqui, uma afirmação muito repetida precisa de correção: a documentação costumava dizer que “/yolo define a variável de ambiente HERMES_YOLO_MODE”. Nunca definiu. São três caminhos de ativação independentes: a flag de CLI hermes --yolo (ou hermes chat --yolo), o toggle /yolo dentro da sessão, e a variável de ambiente HERMES_YOLO_MODE=1. Os dois primeiros têm escopo de sessão, o terceiro tem escopo de processo — não raciocine sobre eles como se fossem a mesma coisa.

As duas direções podem morder

Direção um: você acha que está ligado e está desligado. Esse é o cenário de abertura, e está corrigido.

Direção dois: você acha que está desligado e está ligado. Esse é o novo risco que a correção introduz — um bypass que agora sobrevive a um restart. Duas defesas existentes importam aqui, então use as duas:

• Os lembretes visuais não desaparecem. Enquanto o YOLO está ativo, o Hermes mostra duas pistas persistentes: uma linha de banner vermelha no início da sessão, ⚠ YOLO mode — all approval prompts bypassed (oculta quando o YOLO está desligado, para o banner padrão ficar limpo), e um fragmento ⚠ YOLO na barra de status em todas as faixas de largura, atualizado ao vivo conforme você alterna.
• Duas ações de fronteira sempre o limpam: /new (e o seu alias /reset) e /resume. A primeira é a jogada certa quando você não precisa mais dele, a segunda quando você quer voltar a uma sessão limpa.

Mais uma coisa, para você não tratar o YOLO como chave-mestra: o YOLO só ignora a etapa de aprovação de comandos perigosos. Ele não ignora a blocklist hardline, e não ignora a guarda de ciclo de vida do gateway supervisionado — reiniciar ou matar o gateway de dentro do próprio processo continua sendo recusado, e aprovação do usuário, YOLO e force=True não ajudam em nada. A razão é prática: fazer isso mataria a própria tool que executa o comando, o que dispara um loop de supervisor/auto-resume.

Quando usá-lo, e quando descartá-lo

• Bom encaixe: automação pontual, em contêiner, roteirizada, em que você realmente quer que ele aja sem perguntar, e você já sabe o que ele vai gerar.
• Mau encaixe: exploração interativa, comandos destrutivos sobre os quais você está em dúvida, e qualquer chat usado por mais de uma pessoa.
• Conselho geral: /new quando você terminar. Como um restart não o fecha mais por você, fechá-lo você mesmo é o único resguardo — e o /new é a forma menos esquecível de fazer isso.

Para fechar

• O /yolo antes só mudava um conjunto em memória, então um restart do gateway o descartava silenciosamente enquanto você ainda acreditava que estava ligado.
• Ele agora vive na entrada de roteamento da sessão (SessionEntry.yolo) e sobrevive a restarts, compactação e repontos de sessão, incluindo retomadas na TUI/Desktop.
• /new, /resume, /branch e auto-reset limpam tanto a cópia persistida quanto a em memória — um restart não pode reviver um bypass que você descartou.
• O YOLO suspende apenas os prompts de aprovação; a blocklist hardline e a guarda de ciclo de vida do gateway supervisionado não são afetadas.
• A velha linha da doc de que o /yolo define HERMES_YOLO_MODE estava simplesmente errada — essa variável de ambiente é um caminho de ativação separado.

Já escrevemos sobre aprovações várias vezes, e estes combinam bem: no que os sete modos de YOLO realmente diferem, configuração de aprovações para execuções sem supervisão, e simular as suas regras de aprovação — o último é o que ler quando você mudou as regras de aprovação e não tem certeza se elas vão bloquear algo que você precisa.