O que é o sandbox do Claude Code? Isolamento de arquivos e rede para automação segura (2026)

Use o Claude Code por tempo suficiente e você chega a este dilema. Ele pergunta "posso executar isto?" a cada comando, e seu fluxo trava sem parar. Mas desativar todos os avisos com --dangerously-skip-permissions (ignorar permissões) significa que uma injeção de prompt ou um deslize da mão poderia tocar arquivos por toda a sua máquina. Segurança contra automação — por muito tempo tratado como um trade-off.

O que quebra esse binário é o sandbox. Se você delimitar "o que pode ser tocado" no nível do sistema operacional antecipadamente, os comandos podem rodar livremente dentro da cerca sem avisos, mas nada pode alcançar o exterior. Este artigo apresenta, sob a ótica de quem usa na prática, o que o sandbox do Claude Code isola e como, como começar com /sandbox, como configurá-lo no settings.json, como ele difere dos modos de permissão e os limites em que você não deve confiar demais.

1. Por que você precisa de um sandbox

O Claude Code é um agente de IA que realmente faz coisas — executa testes, reescreve arquivos. É justamente por isso que ele para para perguntar "posso executar isto?" antes de comandos arriscados. Por segurança, isso está correto. Mas quando dezenas de avisos surgem num dia, o trabalho se fragmenta e, no fim, você aperta Enter sem ler. Isso é a "fadiga de permissões".

Um desenvolvedor cansado recorre ao --dangerously-skip-permissions (também conhecido como modo YOLO), que desativa todos os avisos. É confortável e — como o nome diz — perigoso. Três ameaças mostram os dentes de uma vez.

A ideia do sandbox é simples: pare de perguntar "o que devo confirmar?" toda vez, e delimite "até onde isto pode alcançar?" antecipadamente. A cerca é imposta não pelo julgamento do próprio Claude, mas pelo sistema operacional (o kernel), de modo que, mesmo se ele for sequestrado, e mesmo se um comando permitido fizer mais do que o nome sugere, nada escapa do limite. É por isso que comandos dentro da cerca são seguros de executar sem avisos — o binário fadiga-contra-bypass-total desaparece. Em sua publicação oficial de engenharia, "Making Claude Code more secure and autonomous with sandboxing", a Anthropic relata que, em uso interno, o recurso reduziu com segurança os avisos de permissão em 84% (publicado em outubro de 2025).

2. O que é o sandbox — dois isolamentos

O sandbox do Claude Code traça dois limites em torno dos comandos Bash (e de todo processo filho que eles geram). Os dois devem funcionar como um conjunto — qualquer um sozinho deixa uma brecha (veja §7).

O ponto central é que ele não depende do bom comportamento do Claude. O limite é imposto pela própria maquinaria de segurança do sistema operacional — o macOS usa o Seatbelt nativo, o Linux/WSL2 usa o bubblewrap. Assim, o mesmo limite se estende aos scripts que um comando invoca e aos processos netos. Pense nele não como um pedido cortês ao modelo, como as guardrails de IA, mas como um muro físico que se sustenta mecanicamente.

3. Primeiros passos — /sandbox e sistemas suportados

O sandbox é embutido no Claude Code. Nenhuma conta ou ferramenta extra é necessária. Em uma sessão, execute:

/sandbox

Um painel abre com três abas. Mode (como os comandos com sandbox são aprovados — próxima seção), Overrides (se um comando que falha sob o sandbox pode recuar para rodar sem sandbox) e Config (visualizar as configurações resolvidas). No Linux/WSL2, se um pacote necessário estiver ausente, uma aba Dependencies aparece no lugar e informa o que instalar.

Pré-requisitos por SO

No Linux/WSL2, instale o bubblewrap (a ferramenta de sandbox sem privilégios que impõe o isolamento do sistema de arquivos) e o socat (o relé que roteia o tráfego até o proxy).

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

Uma coisa útil de ativar é o filtro seccomp (que adiciona o bloqueio de sockets de domínio Unix). É opcional; instale-o com npm install -g @anthropic-ai/sandbox-runtime. A aba Dependencies do /sandbox mostra o status de ripgrep, bubblewrap, socat e do filtro seccomp. Após instalar os pacotes, reinicie o Claude Code e reabra o /sandbox (a verificação roda na inicialização).

4. Os dois modos (auto-permitir / regular)

A aba Mode escolhe como os comandos dentro do sandbox são aprovados.

Em ambos os modos os limites de sistema de arquivos e de rede são idênticos; a única diferença é "auto-permitir contra aviso". Note que, mesmo no modo auto-permitir, estas válvulas de segurança permanecem ativas:

• Regras de negação explícitas sempre têm precedência
• rm / rmdir visando /, seu diretório home ou outros caminhos críticos do sistema ainda exibem aviso
• Regras de perguntar com escopo de conteúdo, como Bash(git push *), ainda forçam um aviso, mesmo dentro do sandbox

5. Configurando no settings.json

As escolhas no painel /sandbox são gravadas no .claude/settings.local.json do projeto (não versionado no git). Para mantê-lo sempre ativo em todos os projetos, coloque sandbox.enabled: true nas suas configurações de usuário em ~/.claude/settings.json. Ele vive na mesma família de settings.json que as regras de permissão (allow/ask/deny).

Adicionar destinos de escrita, negar leituras

Por padrão, você só pode escrever no diretório de trabalho e na pasta temporária. Se o kubectl ou o terraform precisar escrever em outro lugar, adicione caminhos com allowWrite. Inversamente, você pode bloquear leituras de pastas sensíveis.

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

O exemplo acima nega leituras de todo o diretório home ao mesmo tempo em que continua permitindo o projeto atual (. resolve para a raiz do projeto quando a configuração fica nas configurações do projeto). Os caminhos são impostos no nível do SO, então se aplicam igualmente a processos filhos como npm e terraform.

Proteger credenciais

Uma armadilha importante: o padrão para leituras é "amplamente permitido", então ~/.aws/credentials e ~/.ssh/ ficam legíveis como estão. A configuração dedicada sandbox.credentials (um recurso relativamente recente) declara arquivos cuja leitura deve ser negada e variáveis de ambiente a serem removidas.

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

Permitir destinos

A rede começa com zero destinos. Um novo domínio gera um aviso na primeira vez que é alcançado (nas versões recentes no momento da redação, aprovar uma vez significa que não haverá novo aviso pelo resto da sessão). Pré-registre os hosts sobre os quais você não quer ser questionado em allowedDomains. Com as configurações gerenciadas distribuídas pela organização, você também pode bloquear automaticamente qualquer coisa fora da lista de permissões em vez de exibir um aviso.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    }
  }
}

6. Relação com os modos e regras de permissão

É fácil confundi-los, mas a maquinaria de segurança do Claude Code tem três camadas com funções distintas. O sandbox é uma delas — ele não substitui as outras duas; ele as complementa.

A diferença decisiva é "quando e por quem" cada uma entra em vigor. As regras e os modos de permissão são decididos antes da execução, pelo Claude Code, a partir da string do comando. O sandbox vincula o processo durante a execução, pelo SO — de modo que seja o que o modelo tiver escolhido, e mesmo que um comando permitido faça mais do que o nome sugere, o limite não cede.

Essa é também a diferença decisiva em relação ao --dangerously-skip-permissions (bypass). O bypass apenas remove os avisos; o ambiente permanece totalmente aberto. O auto-permitir do sandbox, por sua vez, consegue pular os avisos porque o muro do SO está lá. A velha regra de ferro — se você usar o modo bypass, apenas dentro de um contêiner ou VM isolado — é algo que o sandbox permite deslocar para o lado seguro mesmo na sua máquina do dia a dia.

7. Limites e ressalvas — não confie demais nele

O sandbox é poderoso, mas não é isolamento completo. Antes de se apoiar nele como um limite de segurança rígido, conheça os limites que a documentação detalha.

Mais uma coisa a internalizar: o escopo é apenas o Bash — as ferramentas nativas Read/Edit/Write, os servidores MCP e os hooks são separados. Para isolar o processo inteiro, incluindo Skills e MCP, envolva o próprio processo do Claude Code com o pacote open-source oficial @anthropic-ai/sandbox-runtime (publicado no GitHub e no npm, um research preview lançado em outubro de 2025). Seu papel prático não é um "muro" contra um atacante determinado, mas um "cinto de segurança" que reduz acidentes e descontroles em ordens de magnitude.

8. Quando recorrer a dev containers ou VMs

O sandbox não é a única opção de isolamento do Claude Code. Conveniência e força do isolamento se compensam, então escolha por finalidade.

A regra prática: mantenha o sandbox embutido sempre ativo para cortar os avisos diários e só suba de nível para o sandbox-runtime, contêineres ou VMs quando você rodar sem supervisão ou lidar com dependências não confiáveis. Para trabalho que chega à produção — como deixar a IA operar a nuvem — combinar credenciais de privilégio mínimo com um nível de isolamento mais forte traz tranquilidade.

Resumo

O sandbox quebra a própria premissa de que segurança e automação devem se compensar. Basta abrir o /sandbox uma vez — só isso já muda a forma como você segura as rédeas do Claude Code. Para a referência de configuração exata e atual, trate a documentação oficial de configurações do sandbox como sua fonte primária.

Perguntas frequentes