O que é o modo YOLO no OpenCode e quando vale a pena usar?

Rodar um agente de código e virar as costas enquanto ele mexe no seu projeto sozinho, sem parar pra pedir confirmação a cada comando

É isso que a galera chama de modo YOLO

Só que já adianto uma coisa importante: no OpenCode isso NÃO é um botão oficial escrito "YOLO" que você aperta

"YOLO" é apelido da comunidade pra rodar o agente com as aprovações desativadas, deixando as permissões em ‘allow’ pra ele não travar pedindo autorização o tempo todo

Bora entender como isso funciona por baixo, e principalmente quando vale (e quando é cilada) ativar 🙂

Como o OpenCode controla o que a IA pode executar

Antes de falar de YOLO, você precisa entender a peça central: o OpenCode tem um sistema de permissões configurável por ferramenta

A ideia é simples: cada coisa que o agente sabe fazer (rodar comando no terminal, editar arquivo, ler arquivo, buscar na web) passa por um filtro

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

E esse filtro tem três estados possíveis:

• allow: roda direto, sem perguntar nada
• ask: para e pede sua aprovação antes de executar
• deny: bloqueia, nem tenta

Isso fica no arquivo de config, o opencode.json, num campo chamado permission

Lá você define ferramenta por ferramenta (tipo bash, edit, webfetch, read), cada uma como allow, ask ou deny

E o padrão de fábrica? A maioria das ações já vem liberada (allow)

Mas tem exceções pensadas pra te proteger: leitura de arquivo é liberada em geral, PORÉM ler arquivos .env é negado (é onde moram suas chaves e senhas, faz sentido) 😀

E tem duas coisas que já vêm em ‘ask’ por padrão: doom_loop e external_directory

E a ordem das regras? Qual vence?

Essa parte é a que mais confunde quem tá começando, então se liga

As regras são avaliadas por correspondência de padrão (pattern match), e a ÚLTIMA regra que casa é a que vale

Por isso o padrão comum é colocar o coringa * primeiro (a regra geral) e as regras específicas depois, pra elas terem a palavra final

E tem um detalhe que salva sua pele: regra de deny explícita é sempre respeitada, mesmo quando você libera o resto

Ou seja, dá pra abrir tudo e ainda manter um bloqueio duro em uma coisa específica que você não quer que ele encoste de jeito nenhum

O modo YOLO na prática: config e o plugin opencode-yolo

Agora que você entendeu o sistema de permissões, o modo YOLO fica óbvio

YOLO no OpenCode é basicamente deixar as permissões em ‘allow’ pra ele não parar pedindo confirmação a cada ação

Não existe um único interruptor mágico, é a própria config de permissões fazendo o trabalho

E repara: mesmo assim, aquelas regras de deny explícitas que você deixou continuam bloqueando

Então "YOLO" não quer dizer necessariamente "sem NENHUM freio", quer dizer "sem PARAR pra perguntar"

O plugin opencode-yolo

Tem também um caminho pela via da comunidade: um plugin chamado opencode-yolo, criado pelo frankhommers

O que ele faz? Ele auto-responde as mensagens do assistente pra você

Na prática, o plugin classifica o texto que o assistente mandou e envia a resposta pendente, dando continuidade sozinho, sem você precisar confirmar ou aprovar na mão

Ele tem até um modo ‘aggressive’ pra quem quer ir com tudo

Mas atenção a um ponto que muita gente pula: esse plugin é de terceiros, NÃO é recurso oficial do núcleo do OpenCode

É um projeto separado no GitHub, mantido pela comunidade

Então vale ler o repositório e entender o que ele faz antes de plugar no seu ambiente, beleza?

Quando vale (e quando não vale) rodar em modo YOLO

Agora a parte que interessa de verdade: autonomia total ajuda ou atrapalha?

Depende MUITO do contexto. Vou separar em dois cenários

Quando o modo YOLO ajuda

• Ambiente descartável: um container, uma VM, uma pasta de sandbox que se der ruim você joga fora e recria. Se nada ali é insubstituível, deixar o agente correr solto economiza um tempão
• Tarefa repetitiva de baixo risco: renomear um monte de arquivo, aplicar o mesmo ajuste em vários lugares, gerar boilerplate. Coisa que você aprovaria clicando "sim" 40 vezes seguidas mesmo, então pra que clicar?
• Prototipagem rápida: aquele projeto de teste que você tá só explorando uma ideia, sem nada em produção

É como contratar um cara fodão e virar as costas: só funciona bem quando o estrago máximo possível é pequeno

Quando é cilada

• Repo de produção: aqui o agente pode rodar bash e mandar ver num comando destrutivo (os rm -rf da vida) sem você ver passar. Um erro e já era
• Dados sensíveis: por isso mesmo o OpenCode já nega .env por padrão. Rodar sem revisão perto de credenciais, banco de dados real, chave de API, é pedir pra se ferrar
• Qualquer coisa irreversível: push forçado, migration de banco, deploy. Coisa que não tem Ctrl+Z

A regra de ouro aqui: mesmo se for de YOLO, mantenha suas regras de deny nas ferramentas perigosas

Como o deny explícito é sempre respeitado, você consegue liberar o fluxo e ao mesmo tempo trancar a porta do que não pode acontecer nunca

Vale ativar o modo YOLO no seu contexto?

Veredito honesto?

O ganho é real: menos interrupção, o agente flui e resolve a tarefa inteira sem ficar te cutucando a cada passo

Mas o custo também é real: ação sem revisão é ação que você não viu acontecer. E o que você não revisa, você não pega o erro antes de ele virar problema

Minha leitura pra decidir:

• Se você tá num ambiente isolado e descartável, YOLO com allow faz todo sentido, pode ir
• Se tem qualquer coisa que dói perder ali no caminho, comece com ‘ask’ nas ferramentas críticas (principalmente bash e edit)

Deixar as ferramentas mais perigosas em ‘ask’ e o resto em ‘allow’ costuma ser o melhor dos dois mundos: fluidez no que é seguro, freio no que é grave

Não precisa ser oito ou oitenta. O sistema de permissões existe justo pra você calibrar isso ferramenta por ferramenta

Se você tá começando do zero no OpenCode e quer sentir a ferramenta rodando com modelo bom sem gastar, esse vídeo do canal mostra como usar o Sonnet 5 de graça (via ZenMux) funcionando também no OpenCode

Bom ponto de partida pra você já ter o agente na mão antes de mexer nas permissões

Conclusão

O modo YOLO no OpenCode não é um botão, é uma escolha de configuração: colocar as permissões em ‘allow’ pra o agente não parar pedindo aprovação

Seu próximo passo prático é abrir o opencode.json, achar o campo permission e decidir com calma, ferramenta por ferramenta, o que fica em allow, o que fica em ask e o que fica em deny

Comece conservador nas ferramentas que rodam comando e editam arquivo, e só solte tudo quando estiver num ambiente que aguenta o tranco

Pra ver todos os detalhes e os padrões atuais, a doc oficial em opencode.ai/docs é a fonte pra consultar

até o próximo post! 🙂