Ao mexer recentemente com LLM CLI (do tipo Codex / Claude Code / Gemini CLI), percebi que “execução automática” não deveria ter só duas opções: ou perguntar em cada passo, ou soltar geral. Pegando o Codex como exemplo, ele divide a automação em dois modos mais práticos:
1) Automação controlada: --full-auto (automático, mas com limites)
A ideia central é “liberar dentro do projeto, frear ao sair do limite”:
- Dentro do workspace pode alterar arquivos e executar comandos automaticamente, reduzindo confirmações frequentes
- Ao envolver arquivos fora do workspace (como
~/.zshrc,/etc/hosts) ou acesso à rede, ele para e pede sua confirmação
É adequado para a máquina principal de desenvolvimento no dia a dia: alta eficiência, com os pontos críticos de risco sob controle.
2) Automação no limite: --dangerously-bypass-approvals-and-sandbox (--yolo)
A ideia central é “pular aprovações + desativar o sandbox”:
- Não pergunta, não bloqueia, praticamente libera tudo
- O risco não é só estragar o código (isso dá para reverter), mas principalmente ações fora do controle do Git: configuração do sistema, instalação de software, baixar dependências pela rede etc.
Só é recomendado para uso de curto prazo em Docker/máquina virtual/ambiente descartável; depois de usar, destrua o ambiente. Não habilite na máquina principal nem em produção.
Complemento: querer menos pop-ups não significa ter que desligar o sandbox
Se você só acha as confirmações frequentes demais, pode manter o sandbox do workspace e apenas ajustar a política de aprovação (por exemplo: perguntar menos dentro do projeto, mas continuar bloqueando quando sair dos limites).
Conclusão em uma frase
No dia a dia, use “automação controlada”; só para experimentos use “YOLO”; se dá para manter o sandbox, não desligue; se dá para manter aprovações, não desative.
Original: https://www.einverne.info/post/806.html