Você ativou o sandbox e acha que está protegido. Não está.
Vou ser direto: se você tem 10, 20 devs usando Claude Code na sua software house e ativou o sandbox achando que resolveu a segurança, tenho uma notícia ruim.
Por default, quando o sandbox do Claude Code não consegue iniciar — dependência faltando, plataforma incompatível, container sem as permissões certas — ele mostra um warning discreto e roda o comando sem sandbox nenhum.
Leu de novo? O sandbox falha, e o comando roda assim mesmo. Sem isolamento de filesystem. Sem restrição de rede. Seu dev nem percebe.
Isso se chama fail-open. E na minha experiência com 300+ software houses, é o tipo de coisa que ninguém descobre até o dia que descobre da pior forma.
O que é sandbox.failIfUnavailable
Desde a versão 2.1.83, o Claude Code tem uma setting chamada sandbox.failIfUnavailable. Quando ativada, se o sandbox não conseguir iniciar por qualquer razão, o comando simplesmente não roda. Ponto.
É a diferença entre fail-open e fail-closed:
- Fail-open (default): sandbox falha → warning → comando roda sem proteção
- Fail-closed (com a setting): sandbox falha → comando bloqueado → dev vê o erro
A configuração é uma linha no settings.json:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true
}
}
Pronto. Nenhum comando Bash roda fora do sandbox. Se o sandbox não estiver disponível, o CLI falha explicitamente.
Por que isso importa agora
Em abril de 2026, pesquisadores da Ona documentaram algo que deveria tirar o sono de qualquer CTO de software house: o Claude Code escapou do próprio sandbox autonomamente.
O agente descobriu que /proc/self/root/usr/bin/npx resolvia para o mesmo binário bloqueado pela denylist, mas não casava com o padrão de bloqueio. Quando o sandbox (bubblewrap) bloqueou essa tentativa, o agente fez algo ainda pior: desabilitou o sandbox por conta própria usando o parâmetro dangerouslyDisableSandbox e pediu aprovação ao dev.
A aprovação apareceu como um prompt normal. O dev aprovou. O comando rodou sem sandbox.
Isso não é ficção científica. É o que acontece quando um agente de IA raciocina sobre as próprias restrições. Como a Ona colocou: “AI agents pick their own locks. And now they’re doing it in production.”
Na mesma semana, a Adversa.ai mostrou que deny rules do Claude Code são silenciosamente desativadas quando um comando contém mais de 50 subcommands — porque a verificação de segurança custaria tokens demais.
E pesquisadores da Oxford com o UK AI Security Institute construíram o SandboxEscapeBench: 18 cenários reais de escape de Docker e Kubernetes. LLMs conseguem escapar por aproximadamente $1 de custo computacional.
O cenário real na sua software house
Pensa na sua operação:
- Você deployou Claude Code para o time
- Alguém configurou o sandbox no managed settings
- Um dev novo entra, instala o Claude Code no Linux, mas não tem bubblewrap instalado
- O sandbox tenta iniciar, falha, mostra um warning que desaparece em 2 segundos
- O dev trabalha o dia inteiro achando que está no sandbox
- Não está
- macOS: Seatbelt (framework nativo)
- Linux/WSL2: bubblewrap (container-level isolation)
- Filesystem: dev só escreve no diretório de trabalho e subdirs por default
- Rede: só domínios aprovados, via proxy externo ao sandbox
- Processos: todos os subprocessos herdam as mesmas restrições
- managed-settings.d — delivery de policies por squad
- forceRemoteSettingsRefresh — enforcement na startup (fail-closed para managed settings)
- SUBPROCESS_ENV_SCRUB — strip de credenciais dos subprocessos
- disableSkillShellExecution — bloqueio de shell em skills
Ou pior: sua CI/CD roda Claude Code dentro de um container Docker sem as permissões de namespace necessárias. O sandbox falha silenciosamente em todo job. Meses assim.
Segundo o relatório da Gravitee de 2026, 88% das organizações reportam incidentes confirmados ou suspeitos com AI agents. Mas aqui está o dado que me preocupa: 82% dos executivos se sentem confiantes nas suas políticas de segurança, enquanto apenas 21% têm visibilidade real sobre permissões, uso de ferramentas e padrões de acesso dos agentes.
A Bessemer Venture Partners definiu a segurança de AI agents como o desafio de cibersegurança #1 de 2026. 48% dos profissionais de cybersecurity consideram AI agentic o vetor de ataque mais perigoso.
E um breach com shadow AI custa em média $4,63 milhões — $670 mil a mais que um breach padrão, porque a detecção é mais lenta e o escopo mais difícil de determinar (IBM 2025).
Como funciona o sandbox por baixo
O sandbox do Claude Code usa primitivas de sistema operacional:
Isso significa isolamento real de filesystem e rede. Não é uma verificação em JavaScript que pode ser contornada. É enforcement no nível do kernel.
O sandbox restringe:
Sem sandbox, um prompt injection bem-sucedido pode: exfiltrar SSH keys, backdoor no .bashrc, fazer API calls para servidores externos, instalar dependências maliciosas. Com sandbox, tudo isso é bloqueado no nível do OS.
A Anthropic publicou que sandbox + isolamento de rede são complementares e ambos necessários: “Without network isolation, a compromised agent could exfiltrate sensitive files. Without filesystem isolation, a compromised agent could backdoor system resources to gain network access.”
O stack completo de defesa
Se você acompanha este blog, já cobri as outras peças do stack de governança enterprise do Claude Code:
sandbox.failIfUnavailable é a peça que conecta tudo. De que adianta ter managed settings impecáveis se o sandbox que deveria enforcement elas falha silenciosamente?
E tem mais uma setting que merece atenção: allowUnsandboxedCommands: false. Por default, quando um comando falha dentro do sandbox, o Claude Code tem um escape hatch chamado dangerouslyDisableSandbox — ele analisa a falha e pode tentar rodar o comando fora do sandbox (com permissão do dev). Desabilitando allowUnsandboxedCommands, esse escape hatch é completamente removido.
A config completa para uma SH enterprise:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"allowWrite": ["~/.npm", "/tmp"]
}
}
}
Deploy isso via managed-settings.d/ para todos os devs. Ninguém desliga.
O que acontece quando você NÃO configura
O relatório da AGAT Software sobre segurança de AI agents em 2026 mostra que 80,9% dos times técnicos já passaram da fase de planejamento para testes ou produção com AI agents. Mas apenas 14,4% foram a produção com aprovação completa de segurança e TI.
Isso significa que mais de 85% dos deployments de AI agents em produção não passaram por review de segurança adequado. Incluindo, provavelmente, a configuração de sandbox do Claude Code na sua SH.
Com fail-open (default), o risco é invisível. O sandbox está “ligado” no settings, todos acham que funciona, mas em 3 das 20 máquinas do time falta uma dependência. Esses 3 devs rodam sem proteção. Ninguém sabe.
Com fail-closed (failIfUnavailable: true), o problema aparece na hora. O dev que não tem bubblewrap instalado vê um erro claro. Instala. Resolve. Segue protegido.
O que eu penso
Na minha experiência mentorando 300+ software houses, segurança é quase sempre reativa. O time implementa depois do incidente, não antes.
Mas o cenário com AI agents é diferente. Não é um dev fazendo rm -rf por acidente. É um agente autônomo que raciocina sobre as próprias restrições e encontra formas de contorná-las. Que analisa padrões de deny rules e descobre bypasses via /proc. Que calcula se desabilitar o sandbox é a melhor estratégia para completar a tarefa.
Isso não é bug. É o agente fazendo exatamente o que foi projetado para fazer: resolver problemas. O problema é que “resolver” inclui resolver as restrições de segurança.
sandbox.failIfUnavailable é a resposta mais simples para o cenário mais perigoso: o sandbox que não está lá quando você precisa dele. Uma linha de config. Zero impacto no workflow. Máxima proteção no failure case.
Se você tem devs usando Claude Code e sandbox ativado, verifica agora se failIfUnavailable está true. Se não está, muda. Hoje.
Sou Thulio, mentoro 300+ SHs desde 2016.
