Claude Code ou OpenCode: qual dá mais controle antes de mexer no seu repositório?

Fala aí, beleza? Poucas coisas dão mais frio na barriga que apontar um agente de IA com acesso de escrita pro repositório da empresa

Não é paranoia, é bom senso: um rm -rf mal colocado, um .env lido sem você ver, um git push que ninguém pediu e o dia já era

O Claude Code e o OpenCode atacam esse medo de jeitos diferentes: regras de permissão em arquivo, modos nomeados de sessão e auto-aprovação

Neste post eu comparo os dois pelo que interessa antes de qualquer edição acontecer: o que cada um pede pra você aprovar, onde essas regras moram e o que dá pra liberar de vez sem se arrepender depois 🙂

Claude Code x OpenCode: como cada um pede aprovação

A base é parecida, mas o comportamento muda no detalhe (e o detalhe aqui é justamente o que te protege)

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Agora linha por linha, porque tabela sozinha não ensina nada

Onde ficam as regras: os dois guardam a política num arquivo de configuração, então dá pra versionar e revisar como código

Valores: os três verbos são os mesmos nos dois lados, o que facilita muito migrar sua cabeça de um pro outro

Granularidade: o Claude Code amarra a regra na ferramenta e no argumento dela, enquanto o OpenCode amarra na ferramenta e (quando você quer) num padrão glob

Ordem de avaliação: essa é a pegadinha do post inteiro

No Claude Code, deny sempre ganha, não importa quão específica seja a regra allow que você escreveu depois

No OpenCode é o contrário da intuição de quem vem do Claude Code: a última regra que casa é a que vale, então a ordem em que você digita muda o resultado

Padrão de fábrica: repara que a maioria das chaves do OpenCode já nasce em allow

Ou seja, instalar e sair usando num repositório de trabalho é bem diferente de instalar e sair usando num projeto pessoal, beleza?

Onde ficam as regras: arquivos, camadas e precedência

Saber o verbo não adianta se você não sabe qual arquivo ganha da briga

A config global do OpenCode é o lugar das preferências de usuário: provedores, modelos e permissões

E tem um extra do lado do OpenCode: dá pra sobrescrever permissões por agente

As permissões do agente são mescladas com a config global, e as regras do agente têm precedência

Já no Claude Code você tem o /permissions, que exibe e gerencia as permissões de ferramentas sem você abrir arquivo nenhum

O exemplo oficial do OpenCode:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "deny",
    "bash": "ask",
    "webfetch": "allow"
  }
}

Legível né? Três linhas e você já sabe o que o agente pode fazer sozinho

E do lado do Claude Code:

A sintaxe é Tool ou Tool(especificador), e as regras entram nos arrays allow, ask e deny dentro de permissions

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "allow": [
      "Bash(npm run build)"
    ],
    "ask": [
      "Bash(curl *)"
    ]
  }
}

As regras acima são exemplos de sintaxe da documentação: em qual array cada uma vai é decisão sua

E se liga nesse ponto, que é o mais esquecido de todos: as regras deny de Read e Edit não valem só pras ferramentas nativas de arquivo

Elas também alcançam comandos de arquivo executados via Bash que o Claude Code reconhece, como cat, head, tail e sed

Sem isso, negar a leitura do .env seria teatro: bastaria um cat .env pra furar a regra

Liberar de vez: modos automáticos, sandbox e auto-aprovação

Agora o outro lado da moeda

Porque ninguém aguenta aprovar prompt o dia inteiro, e os dois projetos sabem disso

E já separo as três coisas que costumam virar uma só na cabeça da galera: os modos nomeados de sessão, o Bash em sandbox (isolamento de sistema de arquivos e de rede aplicado no nível do sistema operacional) e a auto-aprovação da TUI do OpenCode

Os modos nomeados do Claude Code:

São seis: Manual (valor de config default), Edit automatically (acceptEdits), Plan mode (plan), Auto mode (auto), Bypass permissions (bypassPermissions) e Don’t ask (dontAsk), esse último disponível só no CLI

O Shift+Tab troca de modo durante a sessão, só que ele não passeia pelos seis, e isso confunde MUITA gente

O ciclo é default > acceptEdits > plan, e depois do plan entram os modos opcionais, nessa ordem: primeiro bypassPermissions, depois auto

Traduzindo: o atalho passeia por default, acceptEdits, plan, bypassPermissions e auto nessa sequência; quem fica de fora do ciclo é o dontAsk, que só existe no CLI

O acceptEdits aprova automaticamente as operações de arquivo, indicado pra quem prefere revisar as mudanças depois, no editor ou por git diff

Esse é o modo que combina com quem já tem o hábito de versionar tudo antes de soltar o agente, porque o diff vira sua rede de segurança

O plan é o oposto: pesquisa, propõe e não aplica

Se quiser se aprofundar em quando segurar o agente no modo plano, tem post só sobre isso aqui no blog

O bypassPermissions desliga os prompts de confirmação: as chamadas de ferramenta executam imediatamente, sem perguntar

Mas as regras deny continuam valendo mesmo nesse modo: se um deny casa, a ferramenta é bloqueada mesmo em bypassPermissions, então caminhos protegidos por deny seguem protegidos

A documentação recomenda usar apenas em ambientes isolados como containers, VMs ou dev containers sem acesso à internet

E a flag --dangerously-skip-permissions desativa todos os prompts de permissão e deixa o Claude agir livremente, o que a própria Anthropic descreve como inseguro na maioria das situações

O nome da flag já é o aviso, haha

E o auto mode? Quem revisa nele?

Essa é a pergunta certa: no auto mode quem avalia as ações no lugar do usuário é um segundo modelo classificador, não você

A motivação declarada é fadiga de aprovação: os usuários aprovavam cerca de 93% dos prompts de permissão, e quanto mais aprovações a pessoa vê, menos atenção ela dá a cada uma

Sincero? Isso bate com a realidade de qualquer um que já usou agente por algumas horas, você vira uma máquina de apertar "sim"

O número divulgado é que cerca de 83% dos comportamentos overeager são pegos antes de executar

Desde 14 de agosto o auto mode é o modo de permissão padrão de novas sessões nos planos Pro, Max e Team

Pra quem administra time e não quer isso, dá pra desligar pra organização inteira definindo permissions.disableAutoMode como "disable" nas managed settings

Sandbox: outra coisa, e combinável

Muita gente confunde sandbox com auto mode, e são mecanismos separados

O Claude Code tem uma ferramenta Bash em sandbox com isolamento de sistema de arquivos e de rede, aplicando restrição no nível do sistema operacional

Detalhe importante: isso vale apenas pra comandos Bash e seus processos filhos

Com o sandbox ligado e autoAllowBashIfSandboxed no padrão (que é true), os comandos Bash em sandbox rodam sem prompt, mesmo com uma regra ask genérica de Bash nas permissões

A lógica é essa: o auto-allow libera comandos Bash porque a fronteira do sandbox os contém, enquanto o auto mode usa um classificador

Os dois funcionam de forma independente e podem ser combinados

O efeito prático divulgado do sandbox em uso interno foi de 84% menos prompts de permissão

O lado do OpenCode: Build, Plan e a ferramenta Task

O OpenCode é um agente de codificação open source construído pela Anomaly

Ele traz dois agentes primários embutidos, com acesso a ferramentas definido por permissões: o Build vem com todas as ferramentas habilitadas e o Plan vem restrito

Tem também o permission.task, que controla quais subagentes podem ser invocados pela ferramenta Task, usando padrões glob

E aqui vai um detalhe que muda o desenho da sua política: o usuário sempre pode invocar qualquer subagente direto pelo menu de autocomplete com @, mesmo que a permissão de task negasse

Ou seja, permission.task é guardrail pro agente, não cadeado pra pessoa

Qual configuração usar em cada cenário

Chega de teoria, bora ver como isso vira configuração de verdade

1. Repositório de trabalho com dados sensíveis:

Aqui a regra é escrever o deny antes de qualquer outra coisa

No Claude Code, as regras Read(./.env), Read(./.env.*) e Read(./secrets/**) são exatamente os exemplos oficiais de negação de leitura

E lembra do que falei lá em cima: o deny de Read e Edit também alcança cat, head, tail e sed rodados via Bash

No OpenCode, o exemplo oficial já é praticamente a receita conservadora: edit em deny e bash em ask

O erro comum aqui é confiar na ordem errada

Se você está no OpenCode, a última regra que casa vence, então uma regra ampla escrita depois pode reabrir o que você fechou antes

2. Política programável pro time (hooks):

Se o seu time quer regra que pensa, e não só lista, o Claude Code tem os hooks PreToolUse

Eles podem liberar ou bloquear uma chamada de ferramenta no lugar do usuário: o hook retorna hookSpecificOutput com permissionDecision (allow, deny ou ask) e permissionDecisionReason

Ele também pode modificar o input da ferramenta antes da execução, o que abre a porta pra normalizar comando antes de rodar

Mas presta MUITA atenção na hierarquia, porque é ela que evita falsa sensação de segurança:

• uma regra deny bloqueia a chamada e uma regra ask ainda pergunta, mesmo que o hook tenha retornado allow ou ask
• um hook com permissionDecision deny bloqueia a ferramenta até em bypassPermissions ou com --dangerously-skip-permissions

Traduzindo: o hook não te salva de uma regra ask, e nenhum modo maluco te salva de um hook que nega

3. Quem quer velocidade sem largar o volante:

O caminho mais direto é o acceptEdits, aprovando as operações de arquivo e deixando a revisão pro git diff depois

A outra opção é o sandbox com autoAllowBashIfSandboxed no padrão, que tira o prompt dos comandos Bash porque a fronteira do sistema operacional segura a peteca

E, como os dois mecanismos são independentes, dá pra combinar sandbox com auto mode

4. Exploração antes de tocar em código:

No Claude Code, o plan: ele lê, roda comandos de exploração e escreve o plano sem editar o código-fonte

No OpenCode, o agente primário Plan, que já nasce restrito

Esse é o modo que eu abriria numa base que você acabou de clonar e não conhece

5. Automação em máquina isolada:

Aqui entram o bypassPermissions e a auto-aprovação da TUI do OpenCode

Mas repete comigo: ambiente isolado

A recomendação da documentação do Claude Code é usar bypassPermissions apenas em containers, VMs ou dev containers sem acesso à internet

Rodar isso no seu notebook, com credencial de produção no ambiente, é pedir pra aparecer no relato de incidente da semana

Veredito: quem dá mais controle antes de mexer no repositório

Sem empate diplomático: pra controle fino e política de time, o Claude Code entrega mais camadas

Regra com especificador e curinga em qualquer posição, ordem de avaliação definida (deny > ask > allow, primeira correspondência decide), hooks PreToolUse que decidem programaticamente, sandbox no nível do sistema operacional, modos nomeados e até desligamento do auto mode pela organização via managed settings

É mais peça pra montar, e por isso mesmo é mais coisa pra você errar também, seja honesto

Pro lado do OpenCode, o ganho é outro: código aberto (repositório anomalyco/opencode, mantido pela Anomaly), configuração enxuta e legível, e permissão sobrescrevível por agente, com as regras do agente tendo precedência sobre a global

Mas tem um asterisco grande: a maioria das chaves vem em allow por padrão (só doom_loop e external_directory vêm em ask)

Isso significa que apontar o OpenCode recém-instalado pra um projeto sério sem ajustar a config é escolha, não descuido do projeto: a régua está lá, você é que precisa apertá-la

E tem novidade em movimento: o OpenCode 2 está em beta e roda como binário separado, instalando e rodando como opencode2

Na V2, o campo permission virou permissions e passou a ser um array ordenado de regras, cada uma com action, resource e effect, valendo a última regra que casa:

{
  "permissions": [
    { "action": "shell", "resource": "git push *", "effect": "ask" }
  ]
}

Na V2 as permissões globais são aplicadas antes das regras específicas de cada agente, então uma regra posterior do agente pode refinar a global

A recomendação oficial é colocar os curingas amplos primeiro e as exceções depois

E a própria documentação avisa que a beta ainda muda: APIs, configuração e API de plugins podem mudar

Ou seja, se você for construir política de time em cima da V2 agora, conte com retrabalho

Conclusão

O resumo é bem simples: os dois te dão allow, ask e deny, mas o Claude Code te dá mais camadas e mais rede de segurança, enquanto o OpenCode te dá uma config curta que você lê em dez segundos e um padrão inicial permissivo demais pra repositório de trabalho

O próximo passo prático, antes da primeira sessão em projeto sério:

1. abra o /permissions no Claude Code, ou o seu opencode.json no OpenCode, e olhe o que está valendo hoje
2. escreva as regras deny PRIMEIRO (segredo, .env, pasta de credencial), porque negar é o que não pode falhar
3. só depois decida o que automatizar: acceptEdits, sandbox, auto mode, auto-aprovação da TUI
4. e guarde o bypassPermissions pro container isolado, nunca pra máquina onde você trabalha

Regra de bolso: automatize o que você revisaria por git diff, e nunca automatize o que você não conseguiria desfazer

Até o próximo post! =)