Como explicou o capítulo 1, o Claude Code passa por um portão de permissão toda vez que chama uma ferramenta. Imagine isso como um único botão e, no instante em que ele começa a incomodar, você o gira para a posição mais frouxa. Na realidade há a frequência com que você é consultado, a permissão por ferramenta e o isolamento no nível do sistema operacional: três coisas, com funções diferentes. Aperte uma e você pode se dar ao luxo de afrouxar outra, então "seguro ou rápido" não é uma escolha entre dois.

Delegar não é tudo ou nada

O ponto de partida não é o nome de um modo. É "neste trabalho, onde ele deixa de ser recuperável?". Três coisas dizem isso a você.

  • Dá para desfazer? — uma edição que o git reverte custa pouco. Exclusão permanente, um force push, um banco de dados destruído não dá para desfazer
  • Até onde alcança? — fica dentro do diretório de trabalho ou alcança produção, um branch compartilhado, o ambiente de outra pessoa?
  • Toca em segredos? — um vazamento acontece quando conseguir lê-los e conseguir enviá-los para fora valem ao mesmo tempo

As operações chatas são as que são seguras nos três eixos (testes, formatação, edições locais), e as perigosas quase não aparecem. Afrouxe de forma uniforme e você abre o lado perigoso também. Afrouxar por frequência e apertar por natureza é o esqueleto.

Modos de permissão — o que muda de fato

O maior botão é o modo de permissão, que define a frequência geral dos avisos. O Shift+Tab percorre os modos (explicados em modos de permissão do Claude Code).

Pedir permissão (default)

As leituras passam automaticamente, edições e execução de comandos são confirmadas toda vez. O padrão para um repositório que você não conhece.

Aceitar edições (acceptEdits)

Aprova automaticamente as edições dentro da pasta de trabalho. Qualquer coisa fora dela, caminhos protegidos e outros comandos continuam gerando aviso.

Modo de planejamento (plan)

Ele investiga, mas não edita o código-fonte. Você aprova o plano e então ele passa a executá-lo.

Modo automático (auto)

Um modelo avaliador separado olha cada operação antes de ela rodar e barra só as perigosas. Há condições de uso.

Ignorar permissões (bypassPermissions)

Não passa nem pelos avisos nem pelas verificações de segurança. Só para ambientes isolados. Ativo apenas quando iniciado com a flag específica.

Existe também um dontAsk, exclusivo das configurações, que executa a lista de permitidos e os comandos somente de leitura e recusa todo o resto.

Fique de olho também nos caminhos protegidos. Escritas em .git, .claude e na configuração do seu shell não são aprovadas automaticamente nos modos comuns. Você pode colocar o modo padrão nas suas configurações, mas só o modo automático é ignorado nas configurações de projeto: uma linha traçada para que um repositório não consiga ligá-lo sozinho.

O modo automático não é um default mais rápido

Os avisos quase desaparecem, mas nada fica solto: o modelo avaliador barra operações que vão além do escopo do seu pedido, operações que tocam infraestrutura que ele não conhece e operações conduzidas por conteúdo que ele leu. O que passa com facilidade é o trabalho com arquivos dentro da pasta de trabalho e o HTTP somente de leitura. O que é barrado é enviar dados confidenciais para fora, fazer deploy em produção e operações destrutivas de git.

Os limites que você declara na conversa não são salvos. "Não faça push" pode servir de base para um bloqueio, mas é relido da conversa atual a cada vez, então, se a compactação derrubar essa frase, o limite vai junto. Além disso, o modo automático é uma research preview, e a própria Anthropic diz que ele reduz os avisos sem garantir segurança. Ele não substitui a revisão.

Por que você ainda é consultado no modo bypass

Você passou --dangerously-skip-permissions, que deveria pular as confirmações, e o Claude ainda pergunta "posso executar isto?" Nada está quebrado. A permissão tem duas camadas independentes, e o bypass consegue remover apenas uma delas (por que o Claude ainda pede permissão no modo bypass).

Camada 1: a interface de permissão de ferramentas (removível)

"Posso editar este arquivo?" — o diálogo interativo que aparece pouco antes de uma ferramenta ser chamada. Algo que o programa Claude Code coloca na tela.

Camada 2: o julgamento de segurança do próprio Claude (não removível)

"Isto vai alterar o banco de dados de produção, posso prosseguir?" — uma verificação que volta como texto de conversa. Vem dos princípios de comportamento do modelo, então nenhuma flag a interrompe.

Você as distingue por ser interface ou ser texto de resposta. O que dispara a camada 2 é próximo dos três eixos acima: irreversível, de alcance amplo, de alto risco de segurança. Em uma exclusão permanente, em um force push ou em uma migração contra produção, o Claude pausa mesmo com as permissões escancaradas.

Isto é projeto, não defeito. O que o bypass entrega é a chave para usar as ferramentas, não uma chave que desliga o julgamento do Claude. A camada 2 não pode ser reduzida a zero.

Dá para baixar a frequência. Coloque no CLAUDE.md apenas as premissas que você consegue afirmar como fato e torne os pedidos específicos: "apague os arquivos .log em /tmp/" gera menos avisos do que "dê uma limpada nisso". Mas o bypass não é a resposta para "os avisos são chatos" (os riscos do modo bypass e como usá-lo com segurança).

Regras no settings.json — nunca responda a mesma pergunta duas vezes

Se um modo é a frequência geral, as regras de permissão são as exceções por ferramenta e por comando. Você escreve allow (sem aviso) / ask (aviso toda vez) / deny (proibido) no settings.json e compartilha o arquivo (como configurar regras de permissão (allow/ask/deny)).

A avaliação corre deny → ask → allow, e a primeira correspondência vence; ser mais específico não muda a ordem: um deny amplo em Bash(aws *) vence um allow específico em Bash(aws s3 ls). Um deny não comporta exceções. "Eu permiti e mesmo assim ele pergunta" costuma ser apenas outro ask casando primeiro. Como o ask força um aviso até no modo automático, é ali que ficam as operações que você não consegue desfazer.

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

Onde você coloca as regras também tem uma hierarquia. Da mais forte para a mais fraca: configurações gerenciadas (não podem ser sobrepostas) → CLI → settings.local.json → settings.json → ~/.claude/settings.json. Mas um deny em qualquer nível sempre vence um allow em qualquer outro nível. Nos especificadores, um espaço mais * é um limite de palavra (Bash(ls *) casa com ls -la, mas não com lsof).

Do que as regras não protegem você

Tudo o que uma regra olha é o texto do comando prestes a rodar, e qualquer rota que saia desse texto passa direto por ela.

  • Acesso indireto não tem como ser barrado — um deny em Read(.env) funciona contra as ferramentas de arquivo embutidas e contra o cat, mas não funciona contra um script que abre o arquivo
  • Executores de ambiente escondem o conteúdo — devbox run * e docker exec rodam os argumentos ao pé da letra, então um allow em Bash(devbox run *) permite também devbox run rm -rf .
  • Restringir URLs por argumento é frágil — reordenar ou expandir variáveis escapa. Negar curl e wget de saída e nomear os destinos permitidos com WebFetch(domain:) é mais sólido

Escrever "não leia o .env" no CLAUDE.md não é uma regra. O CLAUDE.md muda o que o Claude vai tentar fazer; não muda o que ele tem permissão de fazer. Quem muda isso são as regras, os modos e o hook PreToolUse do capítulo 6 (deny e ask são avaliados independentemente do que o hook devolve).

O sandbox — o que ele consegue cercar e o que não consegue

Quem fecha as rotas que as regras não alcançam é o sandbox: em vez de perguntar "o que eu devo confirmar?", ele cerca de antemão "até onde qualquer coisa consegue chegar?". Quem impõe isso é o sistema operacional (o kernel), e não o Claude, então o limite não se move nem quando um comando já permitido faz mais do que o nome dele sugere (o guia completo do sandbox do Claude Code).

1. Isolamento do sistema de arquivos

Ele pode escrever no diretório de trabalho e em uma pasta temporária, e em nenhum outro lugar (a configuração inicial). O ~/.bashrc e as áreas do sistema não podem ser reescritos.

2. Isolamento de rede

O estado inicial é negar por padrão, com zero destinos. Conectar-se a um domínio novo levanta um aviso, e registrá-lo em allowedDomains faz as perguntas pararem.

Esses dois andam sempre juntos: com apenas um deles, um segredo que ele conseguiu ler vai embora. Há duas formas de aprovação. O modo de permissão automática roda o Bash de dentro sem avisar, enquanto o modo de permissão comum isola e ainda assim deixa os avisos passarem. Mesmo sob a permissão automática, o deny sempre tem prioridade, um rm apontado para um caminho importante é confirmado e um ask específico de conteúdo ainda força um aviso.

Cuidado, porque há duas coisas chamadas "automático". O modo de permissão automática do sandbox quer dizer "deixe passar porque o limite do sistema operacional o contém", enquanto o modo automático do sistema de permissões quer dizer "deixe passar porque o modelo avaliador examinou".

Aprenda primeiro o que ele não protege

O sandbox não é isolamento completo. Deixar isso vago e manter a permissão automática ligada o tempo todo é o estado mais perigoso em que se estar.

  • Ele cobre só o Bash e os processos filhos dele — o Read, o Edit e o Write embutidos, os servidores MCP e os hooks estão fora dele (controle isso com regras de permissão). Para envolver o processo inteiro, use o @anthropic-ai/sandbox-runtime
  • O padrão para leitura é amplo — o que ele cerca é sobretudo a escrita, e ~/.ssh e ~/.aws/credentials são legíveis do jeito que as coisas estão. Feche-os com denyRead
  • Permitir demais vira o buraco — o tráfego é julgado pelo nome do host, e o conteúdo criptografado não é inspecionado por padrão. Permita um domínio amplo e você deixa espaço para as coisas saírem
  • Depende do seu ambiente — o macOS não precisa de nada a mais. Linux e WSL2 precisam de bubblewrap e socat, e o Windows nativo não é suportado

O sandbox não é um muro construído para enfrentar um atacante; é um cinto de segurança que reduz acidentes e comportamento desgovernado em uma ordem de grandeza. A Anthropic declarou que reduziu com segurança os avisos de permissão em 84% internamente, mas isso é um relato de menos avisos, não uma garantia de que não dá para quebrar.

Os acidentes acontecem em basicamente quatro formatos

Aqui está o maquinário alinhado de novo, agora pelo lado do acidente. Escolha as configurações por elas funcionarem ou não contra estes quatro.

1. Comandos destrutivos

O rm varrendo um caminho que ninguém esperava, o git push --force apagando o trabalho de outra pessoa. O que eles têm em comum é serem impossíveis de desfazer. O que funciona são regras de deny e de ask mais isolamento do sistema de arquivos. Jogar em ask as operações que você não consegue desfazer é o movimento confiável.

2. Vazamento de segredos

Isso só vira acidente quando conseguir ler e conseguir enviar se alinham. A contramedida também tem duas partes: não deixe ele ler (um deny em Read(.env), denyRead) e não deixe ele enviar (deny em curl e wget, uma lista estreita de domínios permitidos). Uma das duas não basta.

3. Alcançar outro branch ou outro ambiente

O que você pretendia ser uma correção local de um arquivo cresce até um push para um branch compartilhado ou um deploy em produção: escalada da operação. No modo comum há um aviso em cada degrau, mas escancare tudo e os degraus se achatam. Colocar push e deploy em ask é um seguro barato.

4. Instruções contrabandeadas pelos arquivos que ele lê

Um README, uma issue, uma página web ou um PDF que o Claude leia pode ter instruções dirigidas ao Claude plantadas ali dentro (prompt injection). Mesmo que "envie isto para tal endereço" esteja escrito em texto branco, do lado do Claude aquilo é texto chegando pela mesma porta que o seu pedido, e dados e instruções não se distinguem à primeira vista.

O que não funciona é o modo bypass (o texto plantado chega à execução intocado) e uma proibição escrita no CLAUDE.md (ela não muda o que é permitido). O que funciona é um limite no nível do sistema operacional — ele não consegue escrever onde não pode escrever, nem alcançar o que não pode alcançar — junto com regras de deny. Texto plantado é invisível, então não conte com perceber: leia material não confiável com as permissões estreitadas só para aquela sessão.

Seguro de delegar / precisa ser barrado

Aplique os três eixos e a linha cai aqui.

Seguro de delegar (coloque em allow)

Testes, checagens de tipo, linters, builds / edições dentro do diretório de trabalho / leitura e busca / commits locais

Precisa ser barrado (ask ou deny)

Pushes e force pushes para branches compartilhados / deploys e migrações em produção / leitura de arquivos secretos / comandos que enviam dados para fora / escritas fora do diretório de trabalho

  • Escolha um modo para o dia a dia. acceptEdits para edição repetitiva, default para trabalho sensível. Escreva isso em defaultMode
  • Respondeu ao mesmo aviso três vezes, mova para allow. Na direção contrária, qualquer operação que uma única vez fez você pensar "isso parece arriscado" fica presa em ask
  • Trate qualquer proibição dita na conversa como algo que vai desaparecer.
  • Quando você afrouxar alguma coisa, aperte sempre outra. O único estado que nunca se deve criar é sem avisos e sem limite

Quando o bypass é aceitável. Dentro de um contêiner, uma VM ou um runner de CI que você possa jogar fora se quebrar, com apenas o diretório de trabalho montado e com o .env e as chaves SSH do host mantidos fora dali. "Os avisos são um incômodo" não é motivo. Leia o diff depois, sempre.

Tudo o que foi tratado aqui reduz acidentes; nada disso os elimina. O julgamento da camada 2, os veredictos do modo automático e o limite do sandbox têm todos formatos que passam por eles. Manter-se em um estado que dá para desfazer é o que funciona melhor.

Resumo

  • As permissões são três camadas: modos, regras e o sandbox. Os eixos são dá para desfazer, até onde alcança, toca em segredos, e a regra é afrouxar por frequência, apertar por natureza
  • A permissão tem duas camadas. O bypass remove apenas a interface da camada 1, e a verificação que volta como texto de conversa está funcionando como projetado
  • As regras correm deny → ask → allow e a primeira correspondência vence; a especificidade não muda a ordem
  • As regras só olham strings. Quem fecha essa lacuna é o sandbox, ainda que ele cubra só o Bash e os processos filhos dele e o padrão para leitura seja amplo
  • Os acidentes tomam quatro formatos: comandos destrutivos, vazamento de segredos, alcançar outro ambiente e instruções contrabandeadas

Definido o escopo do que você delega, o resto é fazer isso crescer conforme o seu ambiente. Siga para o capítulo 6, "Estender a ferramenta".