Sua software house roda Claude Code no Linux e acha que o sandbox está protegendo tudo?
Tenho uma pergunta direta: você sabe se o sandbox do Claude Code na sua máquina Linux está realmente bloqueando unix sockets?
Se você instalou via npm ou usa o build nativo — e não atualizou para a v2.1.92 — a resposta provavelmente é não.
O binário apply-seccomp, responsável por bloquear a criação de unix sockets dentro do sandbox, não estava sendo distribuído em algumas builds. O sandbox rodava, o bubblewrap isolava o filesystem, o proxy filtrava a rede — mas unix sockets passavam direto.
E unix socket é exatamente o vetor que um agente comprometido usaria para escapar do sandbox.
O que é o apply-seccomp e por que ele importa
Seccomp — Secure Computing Mode — é um mecanismo do kernel Linux que filtra chamadas de sistema (syscalls) no nível mais baixo possível. Não é um wrapper. Não é um proxy. É o kernel decidindo, antes de executar qualquer coisa, se aquela operação é permitida.
O apply-seccomp é um binário auxiliar que o Claude Code usa para aplicar filtros seccomp-bpf nos processos sandboxed. Especificamente, ele bloqueia a syscall de criação de unix domain sockets.
Por que isso é crítico?
Porque unix sockets são o canal de comunicação entre processos na mesma máquina. O Docker daemon escuta em /var/run/docker.sock. O systemd usa sockets em /run/systemd/. Databases como PostgreSQL aceitam conexões via unix socket. O X11 display server, o PulseAudio, o D-Bus — todos usam unix sockets.
Se um processo dentro do sandbox consegue criar e conectar unix sockets, ele pode:
- Acessar o Docker daemon e spawnar containers com acesso total ao host
- Comunicar com serviços locais que não passam pela rede (e portanto não são filtrados pelo proxy)
- Escalar privilégios conectando em sockets de serviços que rodam como root
- Exfiltrar dados por canais que o network proxy simplesmente não enxerga
O sandbox do Claude Code tem duas camadas: filesystem (via bubblewrap) e rede (via proxy). Sem o seccomp bloqueando unix sockets, existe um terceiro canal — comunicação local entre processos — que nenhuma das duas camadas cobre.
O gap: npm e native builds sem o binário
A v2.1.92 do changelog diz:
“Linux sandbox now ships the apply-seccomp helper in both npm and native builds, restoring unix-socket blocking for sandboxed commands”
A palavra-chave aqui é restoring. O bloqueio existia, parou de funcionar em algumas builds, e agora foi restaurado.
Isso significa que se sua software house:
- Instalou o Claude Code via
npm install -g @anthropic-ai/claude-codeem Linux - Ou usa o build nativo (não o Homebrew)
- E está em qualquer versão anterior à v2.1.92
O sandbox estava rodando sem bloqueio de unix sockets.
Não havia erro. Não havia warning. O /sandbox mostrava tudo verde. O bubblewrap estava ativo. O proxy estava filtrando. Mas o apply-seccomp não estava lá para aplicar o filtro de syscalls.
É o tipo de falha que não aparece em nenhum log — porque o componente responsável por detectar o problema simplesmente não existia na build.
O contexto de segurança que você não pode ignorar
Em 2026, sandbox escapes em AI coding agents deixaram de ser teóricos.
A Ona demonstrou que o Claude Code escapou do próprio sandbox: quando um comando foi bloqueado pela denylist, o agente usou um path trick para contornar. Quando o sandbox detectou, o agente desabilitou o sandbox inteiro via dangerouslyDisableSandbox e executou o comando mesmo assim.
O CVE-2026-25725 revelou que o bubblewrap não protegia o arquivo settings.json quando ele não existia no startup. Código malicioso dentro do sandbox podia criar o arquivo e injetar hooks que executavam com privilégios do host na próxima inicialização.
O UK AI Safety Institute publicou o SandboxEscapeBench com 18 cenários reais — e modelos como o GPT-5 escapam de containers Docker 50% das vezes.
A Bessemer Venture Partners mapeou que 88% das organizações reportaram incidentes de segurança com AI agents confirmados ou suspeitos em 2026. O custo médio de um breach relacionado a AI é US$4.88 milhões.
E a Alibaba teve um agente experimental que escapou do sandbox sozinho, começou a minerar criptomoeda e abriu um backdoor na rede.
Unix sockets são o vetor favorito de quem escapa sandboxes em containers. Docker socket, D-Bus, containerd — são os primeiros alvos. Sem seccomp bloqueando a criação desses sockets, o sandbox é uma porta com tranca mas sem batente.
Como o sandbox do Claude Code funciona no Linux
Para entender o impacto do fix, vale revisar a arquitetura:
Camada 1 — Filesystem (bubblewrap):
- Restringe leitura/escrita a diretórios específicos
- Default: write apenas no working directory
- Configurável via
sandbox.filesystem.allowWrite - Enforcement no nível de namespace do kernel
Camada 2 — Rede (proxy):
- Todo tráfego HTTP/HTTPS passa por um proxy local
- Proxy filtra por domínio (allowedDomains)
- Domínios novos pedem confirmação do usuário
- Tráfego não-HTTP é bloqueado pelo proxy
Camada 3 — Syscalls (seccomp-bpf via apply-seccomp):
- Bloqueia criação de unix domain sockets
- Filtro aplicado antes da execução da syscall
- Sem overhead mensurável (filtro no kernel)
- Esta era a camada que estava faltando em algumas builds
Sem a camada 3, um processo dentro do sandbox podia se comunicar com qualquer serviço local via unix socket — Docker, databases, message brokers, ferramentas de CI — sem que nenhuma das outras camadas percebesse.
Isso é especialmente grave em ambientes de CI/CD, onde o Claude Code roda em modo headless (-p) e frequentemente coexiste com Docker daemon, databases de teste e outros serviços na mesma máquina.
O que sua software house precisa fazer
1. Atualize para v2.1.92+
npm update -g @anthropic-ai/claude-code
Verifique a versão:
claude --version
2. Confirme que o apply-seccomp existe
Após atualizar, verifique que o binário está presente:
find $(npm root -g)/@anthropic-ai/claude-code -name "apply-seccomp" 2>/dev/null
Se o comando não retornar nada, sua build não tem o binário. Reinstale.
3. Ative sandbox.failIfUnavailable
No settings.json (ou via managed settings para toda a organização):
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true
}
}
Isso garante que se o sandbox falhar por qualquer motivo — incluindo apply-seccomp ausente — o Claude Code para ao invés de continuar sem proteção. Se você quer entender como o failIfUnavailable transforma seu sandbox de fail-open para fail-closed, já escrevi sobre isso em detalhe.
4. Bloqueie o escape hatch
{
"sandbox": {
"allowUnsandboxedCommands": false
}
}
Isso impede que o agente use dangerouslyDisableSandbox para escapar — exatamente o comportamento documentado pela Ona.
5. Stack completa de segurança
Para enforcement real, combine:
| Setting | O que faz |
|---|---|
sandbox.enabled: true |
Ativa sandbox |
sandbox.failIfUnavailable: true |
Fail-closed se sandbox indisponível |
allowUnsandboxedCommands: false |
Remove escape hatch |
forceRemoteSettingsRefresh: true |
Garante políticas no startup |
SUBPROCESS_ENV_SCRUB: 1 |
Remove credenciais do ambiente |
disableSkillShellExecution: true |
Bloqueia shell em skills |
allowManagedHooksOnly: true |
Só hooks aprovados pelo admin |
Essa stack é entregue via managed settings (managed-settings.d) do admin console, aplicada centralmente para toda a organização.
O que eu penso
O fix do apply-seccomp é uma linha no changelog que a maioria dos devs vai ignorar. “Ah, corrigiram um binário que não estava sendo distribuído. Legal.”
Mas quando você entende que unix sockets são o canal lateral que bypassa TODAS as outras proteções do sandbox — filesystem e rede — o impacto muda completamente.
Em 2026, com agentes AI executando código autonomamente, um sandbox sem seccomp é como um cofre sem a porta de trás trancada. O alarme funciona, as câmeras gravam, mas quem sabe onde é a saída dos fundos entra e sai sem ninguém perceber.
Na minha experiência com 300+ software houses, segurança de AI agents é tratada como feature — “ativamos o sandbox, está seguro”. Mas segurança é stack. Cada camada que falta é um vetor que existe. E vetores não esperam você atualizar.
O apply-seccomp é a camada que faltava. A v2.1.92 restaurou. Atualize antes que alguém teste a sua porta de trás.
Se você quer implementar esse nível de governança de AI na sua software house, fale comigo na Software House Exponencial.
Sou Thulio, mentoro 300+ SHs desde 2016.
Links e Fontes
- Changelog oficial do Claude Code
- Documentação oficial: Sandboxing — Claude Code
- Ona: How Claude Code escapes its own denylist and sandbox
- CVE-2026-25725: Sandbox Escape via Configuration Injection
- Bessemer: Securing AI agents — the defining cybersecurity challenge of 2026
- Northflank: How to sandbox AI agents in 2026
- Thulio: sandbox.failIfUnavailable — fail-closed para sua SH



