Claude Code todo dia sem susto: onde colocar approval e sandbox

“O diálogo de confirmação aparece de qualquer jeito, então deve estar tudo bem.”

Era exatamente isso que eu pensava quando comecei. Toda vez que o Claude Code ia fazer alguma coisa, surgia uma confirmação. Eu lia, clicava em OK. Tinha a sensação de estar dirigindo com cuidado.

Só que duas semanas depois reparei em como meu próprio dedo estava se movendo, e gelei. Eu apertava Enter no reflexo, sem ler o texto da confirmação. Qualquer ação que já tinha virado “o fluxo de sempre” eu já não revisava mais. git push, escrita em API externa, tudo passava sem eu olhar o conteúdo. Não ter acontecido um acidente foi pura sorte.

Diálogo de approval não é uma coisa que fica mais segura quanto mais você acumula. Em excesso, a pessoa para de ler. De menos, deixa passar até as ações que não dá pra desfazer. Hoje eu vou escrever sobre essa “fronteira”, mas focado não nos detalhes de configuração e sim em como decidir todo santo dia.

Pontos principais

• Approval não é “travar tudo” nem “liberar tudo”: o eixo é deixar rápido o que dá pra desfazer e deliberadamente lento o que não dá. A fronteira é o undo.
• O permission mode (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) você troca conforme a fase do trabalho. Explorar é plan; corrigir revisando é acceptEdits.
• --dangerously-skip-permissions (ou seja, o modo bypassPermissions) não se usa no dia a dia. No lugar, use o modo auto ou o sandbox.
• O sandbox estreita, no nível do sistema operacional, o “alcance” que o Bash consegue tocar. Funciona em macOS / Linux / WSL2 e não funciona no Windows nativo.
• Em time, a “posição do approval” não pode depender da força de vontade das pessoas: fixe ela fisicamente com regras de deny e hooks.

O formato em si dos arquivos de configuração fica no artigo irmão referência de configuração de permissões do Claude Code, e as receitas concretas para combinar CLAUDE.md com permissões estão em CLAUDE.md × receitas de permissão. Este artigo se dedica só à decisão operacional de “onde travar”.

A fronteira do approval é “dá pra desfazer?”

Quando bater a dúvida sobre onde traçar a linha, antes de pensar no tamanho do risco técnico, faça só uma pergunta a si mesmo.

“Isso eu consigo desfazer daqui a 5 minutos?”

Ler um arquivo, fazer um grep, ver um diff, rodar npm run build. Isso você refaz quantas vezes quiser. No pior caso, volta com git checkout. Por isso quero que rode rápido. Já git push, deploy de produção, envio de e-mail, escrita em banco externo: no instante em que você aperta, o mundo lá fora muda. Não tem como desfazer. Por isso eu deixo lento de propósito.

A divisão em três camadas que eu costumo usar é esta.

Ação	Decisão	Motivo
Ler, grep, diff, build, test, lint	allow	Dá pra desfazer. Não quero perder velocidade
Editar código na branch	ask ou acceptEdits	Depende da maturidade do repositório
push, deploy, publish, envio de e-mail, escrita em API externa	ask	Afeta o mundo lá fora. Não dá pra desfazer
Ler .env, rm -rf, git reset --hard, curl | sh	deny	O estrago em caso de acidente é grande demais

O ponto que mais gera dúvida aqui é a “edição”. Edição não é perigosa por natureza. Num repositório pessoal com testes bem montados, não dá medo deixar a edição rodar rápido. O que assusta mesmo é deixar a edição solta num repositório próximo de produção e com testes fracos. Por isso o critério não é “permitir editar?” e sim com o que você verifica depois de editar. Se os comandos de verificação estão prontos, pode deixar a edição rápida. Se não estão, deixe em ask.

Em deny, colocar coisas “por garantia” de forma generosa não tem prejuízo. Leitura de .env e comandos destrutivos: bloqueie desde o início, partindo do princípio de que nunca vai chegar o dia de promovê-los para allow. As instruções do tipo “ignora as permissions e faz no modo mais rápido” que listei em coletânea de prompts perigosos são justamente o ato de quebrar essa fronteira de propósito. Se estiver no deny, não importa o que o prompt mande: o próprio Claude Code trava.

O permission mode você troca por fase

Se allow/ask/deny é a configuração de “o quê” travar, o permission mode é a escolha de marcha de “quanto travar agora”. Com Shift+Tab você alterna default → acceptEdits → plan. A documentação oficial de permission modes reúne todos os modos, mas o que vale memorizar para o uso prático é esta correspondência.

Modo	Alcance que roda sem confirmar	Quando usar
default	Só leitura	Repositório novo, trabalho que quero conduzir com cautela
plan	Só leitura (não edita, só monta o plano)	Quero entender a base de código antes de mexer
acceptEdits	Leitura + edição dentro da pasta de trabalho	Corrigir revisando eu mesmo
auto	Quase tudo (um classificador checa segurança nos bastidores)	Trabalho longo, quero reduzir o cansaço de confirmar
dontAsk	Só o que foi liberado em allow antes	CI ou ambiente fechado de scripts
bypassPermissions	Tudo (sem checagem)	Só dentro de container/VM isolado

Meu critério é simples. A porta de entrada de todo trabalho novo é o plan. Deixo o Claude ler primeiro, fazer ele expor o roteiro, e só depois de confirmar que a direção bate é que mando ele agir. Quando a direção está firmada, caio para acceptEdits e mando editar de uma vez, e olho o resultado de uma vez só com git diff. Aprovar linha por linha cansa mais do que ler tudo junto depois com a cabeça focada. Isso é transformar o “olhar no final, sem falta” em mecanismo, e segue na mesma linha do “colocar o porteiro na máquina” que escrevi em engenharia de harness.

Um ponto de atenção. Em qualquer modo, com exceção do bypassPermissions, escrita em protected paths não é aprovada automaticamente. São lugares como .git, .claude, .bashrc, .npmrc: se quebram, o repositório ou a própria configuração morrem. Mesmo editando à vontade no acceptEdits, só aqui entra confirmação. Não veja isso como estorvo; veja como a última rede de segurança.

Como passar longe do --dangerously-skip-permissions

Tentando resolver o “tem confirmação demais, que saco”, muita gente estica a mão para o --dangerously-skip-permissions (ou seja, o modo bypassPermissions). Como o nome diz, é a flag que desliga todas as checagens.

Se você usar isso o tempo todo no diálogo do dia a dia, já não é mais um “agente com supervisão”. É só que, por acaso, ainda não houve acidente. A própria documentação oficial deixa explícito que esse modo é “só dentro de container/VM isolado”: fora os casos mais catastróficos como rm -rf / ou rm -rf ~, não aparece prompt nenhum. A defesa contra prompt injection também é zero.

Mas o sentimento de “que saco” em si está certo. Por isso, o que se deve eliminar é a quantidade de confirmações, não a rede de segurança. Há duas alternativas.

Uma é o modo auto. Ele apaga as confirmações, mas um outro modelo classificador observa cada ação nos bastidores e bloqueia as perigosas: curl | bash, deploy de produção, push direto na main, force push. Se durante a conversa você disser “não dá push”, isso também funciona como sinal temporário de bloqueio. As confirmações caem, e mesmo assim as ações perigosas travam. É algo diferente do bypassPermissions. Só que o modo auto é research preview, então não é uma ferramenta para pular inteira a revisão de operações sensíveis; é para usar em “trabalho cuja direção você confia”.

A outra é o sandbox. Explico no próximo capítulo.

Se quer reduzir confirmações, primeiro acceptEdits ou auto; se ainda não bastar, sandbox. O bypassPermissions você trata como exclusivo de container. Pensando nessa ordem, quase não sobra motivo para tirar toda a rede de segurança.

O sandbox amarra “o alcance que dá pra tocar” via sistema operacional

Se o approval é o mecanismo que pergunta “pode fazer essa ação?”, o sandbox é o mecanismo que estreita, no nível do sistema operacional, o próprio alcance de arquivos e rede que o Bash consegue tocar. Approval é “checagem antes de executar”; sandbox é “parede durante a execução”. São camadas diferentes.

O que faz isso valer a pena é que ele cobre o ponto fraco do approval. Como o approval decide olhando a string do comando, se o npm run build fizer algo inesperado por baixo dos panos, ele não percebe. Mas com o sandbox, aquela mesma ação só pode escrever, por padrão, dentro da pasta de trabalho. Mesmo que o comando não se comporte como o nome promete, o sistema operacional trava fisicamente.

Quando você executa /sandbox, abre um painel de configuração com dois modos.

• auto-allow: dentro do sandbox, executa Bash sem confirmar (é seguro porque o alcance está contido). Só as ações que saem do alcance voltam para o approval normal.
• regular permissions: mesmo dentro do sandbox, emite approval como de costume. O controle é forte, mas há muita confirmação.

Ou seja, é perfeito para quem pensa “quero reduzir as confirmações, mas tenho medo de tudo ser executado”. Como a proteção é por alcance, não precisa ficar perguntando a cada passo.

Há, porém, uma restrição importante. O sandbox roda só em macOS / Linux / WSL2 e não funciona no Windows nativo. Quem usa Windows precisa rodar o Claude Code dentro do WSL2. Se você não consegue usar o WSL, ou usa o Windows puro, não conte com o sandbox e deixe a divisão allow/ask/deny mais rígida. Em especial, puxe deploy, publish e tudo que envolve secret para ask. Esse é o desfecho realista no Windows.

A configuração do sandbox tem este formato. Só para as ferramentas que precisam escrever fora da pasta de trabalho (por exemplo, o kubectl toca em ~/.kube) é que você abre um furo explícito.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false é a configuração que diz “se for um ambiente onde o sandbox não roda, só emite um aviso e cai para a execução normal”. Por outro lado, se a organização quer tornar o sandbox obrigatório, coloque true para travar a própria inicialização. E uma coisa discretamente importante é o denyRead. O padrão do sandbox consegue ler quase todos os arquivos, então bloquear explicitamente segredos como ~/.aws e ~/.ssh traz tranquilidade.

O ponto de partida que cabe na “operação diária”

Reunindo todas essas decisões num único arquivo, este é um ponto de partida mais do que suficiente para a operação do dia a dia. O significado miúdo do formato (a diferença entre Bash(npm run build) e Bash(npm*), por exemplo) eu deixo para a referência de configuração de permissões.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

São só três coisas que estou fazendo. Deixar leitura e verificação rodando rápido. Travar sem falta as ações que afetam o lado de fora. Proibir desde o início as que são claramente perigosas. Coloquei defaultMode: "plan" porque quero começar toda sessão nova por “primeiro ler e planejar”. Depois é só ir subindo para acceptEdits com Shift+Tab enquanto trabalha.

Não escrever edição (Edit / Write) nem em allow nem em ask é intencional. Porque quero controlá-la pelo lado do mode (acceptEdits). Se você amarra a edição pelos dois lados, regra e modo, fica sem saber qual está valendo. Separar os papéis como edição no modo, efeitos colaterais externos na regra deixa a cabeça organizada.

Em time, fixe a “posição do approval” no físico

Até aqui foi sobre o uso individual. Em time, surge mais um problema. A fronteira fica diferente de pessoa para pessoa. Tem quem seja cauteloso e tem quem queira rodar tudo no bypassPermissions. Se você depende de força de vontade e bom senso, a operação da pessoa mais frouxa vira a linha efetiva do time.

Por isso, os lugares que você quer travar não devem ficar a cargo da decisão das pessoas: fixe no físico. Três exemplos concretos.

1. Travar vazamento de secret antes do commit. Num hook de PreToolUse, antes do git add, cheque por máquina se algum .env foi para o stage. Antes da pessoa perceber “ué, isso aqui não podia ter entrado”, o commit já trava.

2. Forçar build antes do deploy. Não acredite no “achei que tinha passado o build local”. Antes do comando de deploy, faça um hook rodar npm run build sem falta.

3. Rodar verificação automática depois de editar. Depois de Edit / Write, dispare npm run test. Como a verificação roda até em correção pequena, não dá pra seguir com algo quebrado.

A configuração mínima é mais ou menos esta. Hook não é melhor quanto mais você tem; algo como um hook que trava e um hook que verifica é o que menos quebra a operação.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Bloqueado: .env no stage' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

No Windows, é só trocar a parte do grep por findstr ou um pequeno script em Node que funciona. O importante não é o comando em si, e sim os três formatos: “travar antes do commit / build antes do deploy / verificar depois de editar”. Para amarrar em nível de organização, dá também para usar managed settings, deixar bypassPermissions como disable e tornar o sandbox obrigatório. Quando chegar ao tamanho de time, projetar isso junto com as regras de operação na página de consultoria acaba sendo, no fim, o caminho mais rápido.

Falhas comuns

As três foram coisas que eu ou alguém perto de mim fez de verdade.

Colocar tudo em ask e ficar satisfeito

No primeiro dia parece seguro. Mas uma semana depois você começa a apertar OK sem ler o texto da confirmação. Isso é mais perigoso do que estar com o deny fraco. Porque sobra a ilusão de “achei que tinha conferido”. Antes de enfileirar asks, firme primeiro o deny.

--dangerously-skip-permissions virar vício de linguagem

Depois que você experimenta uma vez o “nossa, que rápido”, não consegue mais voltar. Mas isso é só ter tirado a supervisão. Se confirmar dá saco, use o modo auto ou o auto-allow do sandbox. Não há nenhum motivo para tirar junto a rede de segurança inteira.

Confundir build com sucesso com release com sucesso

Isso aparece muito tanto em operação de conteúdo quanto em desenvolvimento. O build local passou, mas a URL pública está velha, só um idioma não foi atualizado, o CTA está quebrado no celular. Approval e sandbox não previnem essa falha. O que se precisa é da conferência depois de publicar. Eu já fiz esse “achei que tinha publicado” um monte de vezes.

Perguntas frequentes

P. Qual a diferença entre o modo auto e o auto-allow do sandbox? R. O jeito de proteger é diferente. O modo auto usa um modelo classificador para julgar “essa ação é perigosa?” e bloquear. O auto-allow do sandbox não olha o conteúdo da ação: garante a segurança amarrando o “alcance que dá pra tocar” via sistema operacional. O primeiro protege por julgamento, o segundo por alcance. Dá até para combinar os dois.

P. Dá para usar o sandbox no Windows? R. No Windows nativo, não. Se você rodar o Claude Code dentro do WSL2, dá. No Windows puro, não conte com o sandbox: puxe deploy, publish e secret para ask e deixe o deny mais rígido.

P. Como eu separo o uso do modo plan e do acceptEdits? R. O plan é “só ler, não editar”, para a fase de entender a base de código e montar o roteiro. O acceptEdits é “deixar passar sem confirmar as edições dentro da pasta de trabalho”, para a fase de corrigir de uma vez quando a direção está firmada. Eu começo no plan e, quando há acordo, caio para o acceptEdits.

P. E quando eu preciso executar, só uma vez, uma ação que está no deny? R. O deny é forçado pelo próprio Claude Code, então não dá para afrouxar pelo prompt (esse é o valor do deny). Se for realmente necessário, tire ele do settings na hora, execute, e devolva quando terminar. O próprio trabalho de “tirei temporariamente” funciona como freio para ações perigosas.

P. Hook e permission não têm papéis sobrepostos? R. Não se sobrepõem. A permission controla “pode executar essa ação?”, e o hook controla “o que rodar sem falta antes e depois da execução”. Checagens determinísticas como travar vazamento de secret ou rodar build antes do deploy são responsabilidade do hook.

O resultado de testar na prática

Eu reapliquei esse raciocínio direto na daily automation deste site. O que mais mudou não foi a qualidade do output da IA em si, e sim o fato de ter ficado claro em que momento o humano para.

Antes era uma operação vaga de “tocar uma coisa qualquer pra frente”, e às vezes o run terminava com uma correçãozinha num artigo já existente. Agora está fixado o fluxo montar o roteiro no plan → editar no acceptEdits → build pelo hook antes do deploy → conferir todos os idiomas no celular depois de publicar. Desde que parei de usar o bypassPermissions e mudei para acceptEdits + sandbox, sumiu aquele frio na espinha de “quando vi, já tinha feito algo lá fora”.

Em vez de largar tudo na mão de uma IA esperta, colocar uma respirada antes das ações que não dá pra desfazer. Parecia um desvio, mas foi assim que consegui rodar tranquilo todo dia. Para começar, deixe o cheatsheet gratuito ao lado e preencha sua lista de deny, uma linha de cada vez.