Sandbox no Claude Code: menos aprovações, mais segurança

Se você usa o Claude Code há algumas semanas, conhece bem este ritual: o agente está indo bem, resolvendo a tarefa, e a cada dois passos a tela trava esperando você apertar "sim" pra rodar um npm test, um git status, um ls. No começo você lê cada comando com atenção. Depois de cinquenta aprovações no mesmo dia, você só aperta no automático — e é exatamente aí que mora o perigo: a permissão que deveria te proteger virou um clique reflexo que não protege nada.

A Anthropic resolveu esse problema de um jeito elegante: o sandbox do Claude Code. Em vez de te perguntar a cada comando, ela cria uma cerca em volta do agente. Dentro dela, o Claude roda livre. Pra sair dela, aí sim ele precisa de você. O resultado, segundo a própria Anthropic, é uma queda de 84% nos pedidos de permissão — sem abrir mão da segurança. Vamos entender como isso funciona e como ligar.

O que é o sandbox (e por que ele é diferente)

Sandbox quer dizer "caixa de areia": um espaço cercado onde o que acontece ali dentro não vaza pra fora. No Claude Code, essa cerca tem duas paredes.

A primeira é o disco. Por padrão, comandos dentro do sandbox só conseguem escrever na pasta do seu projeto (e numa pasta temporária). Se um comando tentar modificar seu ~/.bashrc, um binário em /bin/ ou qualquer coisa fora do projeto, o sistema operacional barra na hora — com um "operação não permitida" lá no nível mais fundo, não numa checagem que dá pra enganar.

A segunda parede é a rede. Nenhum domínio vem liberado de fábrica. A primeira vez que um comando tenta acessar um site novo, o Claude Code te pergunta. Você libera github.com, por exemplo, e dali pra frente as conexões pra ele não perguntam mais — mas qualquer domínio fora da lista esbarra na parede.

O detalhe que muda tudo: quem garante essas paredes é o sistema operacional, não o Claude. No macOS é o Seatbelt; no Linux e no WSL2, o bubblewrap. Como a regra é aplicada no kernel, ela vale pra todo comando e pra todo processo-filho que ele abrir. Não importa o que o modelo decidiu rodar nem se um comando faz mais do que o nome sugere — a cerca segura.

Por isso o Claude pode rodar comandos sem te perguntar: a segurança parou de depender de você revisar cada ação no cansaço.

A diferença pro modo perigoso

Muita gente já usava o --dangerously-skip-permissions (o famoso "modo perigoso") justamente pra fugir das aprovações. Mas as duas coisas são opostas:

• --dangerously-skip-permissions: desliga as perguntas e não cria cerca nenhuma. O Claude pode tocar em qualquer arquivo da máquina. É autonomia no escuro.
• Sandbox: também reduz as perguntas, mas porque existe um limite real que o sistema garante. É autonomia com rede de proteção.

Se você adotou o modo perigoso por preguiça das permissões, o sandbox é o upgrade óbvio: você ganha a mesma fluidez sem a exposição.

Como ligar em 3 passos

No macOS não tem o que instalar — o Seatbelt já vem no sistema. No Linux ou WSL2, instale os dois pacotes que a cerca usa:

sudo apt-get install bubblewrap socat   # Ubuntu/Debian

Depois, dentro do Claude Code, abra o painel:

/sandbox

O painel tem três abas. Na aba Mode, escolha entre dois modos:

• auto-allow: comandos dentro do sandbox rodam sem pedir permissão. É o que corta as 84% de aprovações.
• regular permissions: a cerca continua valendo, mas o Claude ainda pede confirmação. Mais controle, mais cliques.

Pronto. Peça uma tarefa que mexe bastante no terminal — rodar os testes, um build — e repare: o trabalho flui sozinho, e o Claude só te chama quando um comando precisa sair da cerca, tipo baixar algo de um domínio que você ainda não liberou.

Pra deixar o sandbox ligado em todos os projetos, coloque isto no seu ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true
  }
}

Cuidado nº 1: a leitura ainda é liberada

Aqui está a pegadinha que muita gente não percebe. A parede de disco bloqueia escrita fora do projeto — mas a leitura continua liberada pra quase tudo. Ou seja: por padrão, um comando dentro do sandbox ainda consegue ler seu ~/.aws/credentials e sua pasta ~/.ssh.

Pra fechar isso, declare suas credenciais no bloco sandbox.credentials. Ele nega a leitura dos arquivos que você listar e ainda apaga variáveis de ambiente secretas antes de cada comando rodar:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

A regra de ouro da Anthropic: isolamento de disco sem isolamento de rede não serve de nada, e vice-versa. Se um agente comprometido não pode escrever fora do projeto mas pode ler suas chaves e mandar pela internet, você não protegeu nada. As duas paredes trabalham juntas.

Cuidado nº 2: nem todo comando entra na cerca

Algumas ferramentas simplesmente não rodam dentro do sandbox. O docker é incompatível. O jest trava por causa do watchman (rode jest --no-watchman). No macOS, CLIs em Go como gh e terraform podem falhar na verificação de TLS.

Quando isso acontece, o Claude Code tem uma saída de emergência: ele percebe que o comando falhou por causa da cerca e tenta de novo fora dela — aí sim pedindo sua permissão pelo fluxo normal. Se um comando específico precisa sempre rodar solto, você o adiciona na lista excludedCommands. Nada de desligar o sandbox inteiro por causa de uma ferramenta teimosa.

Vale saber também que o sandbox cerca só os comandos de terminal (Bash) e seus processos-filhos. As ferramentas internas de ler e editar arquivo seguem pelo sistema de permissões normal. E os subagentes herdam a mesma configuração de sandbox da sessão principal — então a cerca vale pra eles também.

Vale a pena ligar?

Pra quase todo mundo, sim. Se você vivia apertando "sim" no automático, o sandbox devolve a fluidez sem o risco que o modo perigoso trazia. E menos interrupção costuma andar junto com menos retrabalho — o agente mantém o ritmo em vez de parar a cada passo, o que também ajuda a gastar menos tokens com idas e voltas.

Só não confunda "mais seguro" com "blindado". A própria documentação é honesta: o sandbox reduz o risco, não é uma muralha perfeita. O proxy de rede filtra por domínio, mas não inspeciona o conteúdo do tráfego; liberar domínios largos demais abre brecha. Trate o sandbox como o que ele é: uma cerca muito boa pro dia a dia, que você ainda precisa configurar com um pouco de cuidado — começando por proteger suas credenciais.

Fonte: anúncio oficial da Anthropic em Making Claude Code more secure and autonomous with sandboxing e a documentação do sandbox. Os fatos e números vêm de lá; a explicação, os exemplos e o recorte em português são deste blog.