Você usa mais de um agente
ai-jail: um único arquivo de política, qualquer comando, o processo inteiro lá dentro. Instalar.
Comparar
Seu agente já tem um sandbox. Ele cobre a outra metade.
Sandboxes embutidos e pedidos de permissão vigiam os comandos que o modelo executa. O ai-jail decide o que o programa do agente inteiro enxerga na sua máquina, e é ajustado para os erros de um agente confiável. Os dois funcionam juntos.
Para quem está escolhendo entre ferramentas. As seis situações do topo respondem a maioria das perguntas.
Última revisão em 15 de outubro de 2026. Os outros produtos mudam rápido, então cada afirmação sobre eles tem link para a documentação do próprio fornecedor.
Resumindo
Seis situações, uma resposta para cada. O resto da página mostra as evidências.
Você só usa o Claude Code
O sandbox-runtime da própria Anthropic também envolve o processo inteiro, em beta; o ai-jail acrescenta um home vazio e uma rede fechada. Veja os cards.
Você quer o sandbox e os pedidos de permissão do próprio agente
Deixe ligados. Eles funcionam dentro do ai-jail. Use os dois.
Você quer políticas por ferramenta, aprovações em tempo de execução e uma trilha de auditoria assinada
O nono vai mais longe nisso, ao custo de uma linguagem de políticas e um supervisor. Compare os wrappers.
Você cria sandboxes a partir do código, uma chamada de ferramenta por vez
O zerobox tem SDKs para isso; deixa as leituras abertas e não tem release desde maio de 2026. Compare os wrappers.
Você não confia no código de jeito nenhum
Uma máquina virtual descartável. Toda ferramenta desta página compartilha o seu kernel. Docker, containers e VMs.
Onde fica o muro
No momento em que este texto foi escrito, o sandbox do Claude Code vale para comandos de shell e seus processos filhos. As ferramentas de arquivo dele usam o sistema de permissões, e a documentação diz que servidores MCP e hooks rodam sem restrição no host. O ai-jail inicia o próprio agente dentro do muro, então tudo o que ele dispara também fica lá dentro.
↔ Deslize para o lado para ver o diagrama inteiro
O Codex também coloca em sandbox os comandos que dispara e deixa o processo codex do lado de fora. A documentação dele diz que os servidores MCP usam processo ou transporte próprios, fora do sandbox.
Pedido de permissão é outro tipo de proteção
Um pedido de permissão pergunta a uma pessoa, e uma pessoa pode estar com pressa ou ser enganada. Um sandbox pergunta ao kernel, que dá a mesma resposta todas as vezes.
↔ Deslize para o lado para ver o diagrama inteiro
Modos que tiram a pessoa do caminho
No momento em que este texto foi escrito, cada um destes agentes tem um modo que para de perguntar. Sem o pedido de permissão, o sandbox é a única proteção que sobra, se houver algum ligado.
| Agente | Modo | O que o fornecedor diz que ele faz |
|---|---|---|
| Claude Code | auto | Tudo roda e um segundo modelo revisa as ações no seu lugar. A documentação chama esse classificador de um controle por ação, não uma fronteira de isolamento. |
| Claude Code | bypassPermissions, também --dangerously-skip-permissions | Tudo roda sem nenhuma verificação. A documentação diz para usar só em containers e VMs isolados. |
| Codex CLI | Política de aprovação never | O agente nunca pergunta. O modo de sandbox continua valendo. Veja aprovações e segurança. |
| Codex CLI | danger-full-access, ou --yolo | O sandbox fica desligado. Com --yolo também não há aprovações. |
Lado a lado
Tudo aqui descreve a documentação de cada produto no momento em que este texto foi escrito. Quando a documentação que lemos não responde a uma pergunta, a célula diz isso.
| Sandbox do Claude Code | Sandbox do Codex CLI | Sandbox do Gemini CLI | ai-jail | |
|---|---|---|---|---|
| O que um wrapper em volta do agente inteiro acrescenta | ||||
| O que fica dentro do muro | Comandos do Bash, do PowerShell e do Monitor e seus processos filhos. O processo claude, suas ferramentas de arquivo, servidores MCP e hooks ficam de fora. | Os comandos que o agente dispara. O processo codex fica de fora. A documentação diz que servidores MCP locais e remotos usam processo ou transporte próprios, então também ficam de fora. | O processo inteiro da CLI, ou só as ferramentas de shell e de escrita com security.toolSandboxing. | A árvore de processos inteira: o agente, suas ferramentas de arquivo, servidores MCP, hooks e todos os comandos. |
| Ligado por padrão | Não. Você liga com /sandbox ou sandbox.enabled. Se faltar uma dependência, ele avisa e roda os comandos sem sandbox, a menos que você defina sandbox.failIfUnavailable. | Sim. workspace-write é o modo padrão. | Você liga com -s, GEMINI_SANDBOX ou tools.sandbox. | Fica ligado sempre que você inicia o agente por ele. Se a configuração for inválida, ele se recusa a iniciar. |
Código no sandbox consegue ler ~/.ssh por padrão? | Sim. A documentação diz que o padrão ainda permite ler arquivos de credenciais como ~/.aws/credentials e ~/.ssh/. As regras de negação são opt-in. | Sim no Linux, onde o sistema de arquivos inteiro é montado como somente leitura. Um perfil de permissões pode acrescentar regras deny para caminhos como **/.env*, e a configuração reforçada da própria OpenAI faz isso. Padrão no macOS: não documentado. | O perfil padrão no macOS, permissive-open, permite leitura ampla de arquivos. Perfis mais restritos são opt-in. | Não. O agente recebe um diretório home novo e vazio. --ssh é opt-in. |
| Variáveis de ambiente | Os comandos no sandbox herdam o ambiente do processo pai por padrão, com as credenciais. sandbox.credentials pode negar ou mascarar essas variáveis. | Não documentado | Não documentado | Uma allowlist mínima com variáveis de terminal, locale e toolchain, mais a chave de API do próprio harness iniciado, copiada por padrão junto com o login dele; --no-agent-state impede isso. Você acrescenta outras pelo nome com --env. |
| Saída de emergência que o modelo pode usar | O modelo pode tentar o comando de novo com dangerouslyDisableSandbox, que passa pelo fluxo normal de permissões. allowUnsandboxedCommands: false desliga isso. | Com a política on-request, o agente pede para sair do sandbox quando precisa editar fora do workspace ou usar a rede. | Não documentado | Nenhuma. Você define a política antes de o agente iniciar, e o arquivo .ai-jail do próprio projeto pode apertá-la, nunca abrir. |
| Funciona com qualquer agente | Só Claude Code | Só Codex | Só Gemini CLI | Qualquer comando, com um único arquivo de política para todos os seus agentes. |
| Modelo de rede | Um proxy com allowlist por domínio. Um domínio novo gera um pedido de permissão, e cada comando ainda passa pela própria aprovação. A documentação observa que o proxy confia no hostname que o cliente envia, então domain fronting consegue contorná-lo. | Desligada por padrão em workspace-write. Uma configuração liga a rede, e um proxy opcional acrescenta regras de permissão e negação por domínio. A documentação diz que o proxy não filtra as conexões de servidores MCP, a busca na web nem o navegador. | O perfil padrão permite rede. Perfis mais restritos e com proxy são opt-in. | Três modos. O padrão é fechado, exceto o host da API de um agente conhecido nas duas plataformas e, no Linux com as toolchains ligadas, uma lista fixa de registries de pacotes que inclui github.com, então git clone por HTTPS funciona; --no-network fecha os dois. --allow-host acrescenta hosts e seus subdomínios, com a cerca no network namespace no Linux ou numa regra de endpoint do seatbelt no macOS, por um proxy que resolve cada nome uma vez e disca o endereço que conferiu. --network abre tudo. O filtro é só TCP, não tem regras por caminho e nunca pergunta: um host fora da lista é negado, e --audit-log registra a tentativa. Um host permitido é confiável por inteiro. No Linux, --forward-port repassa uma porta do loopback do host para dentro do sandbox, sem nenhuma regra sobre o que passa por ela. |
| O que os sandboxes embutidos fazem melhor | ||||
| Aprovação a cada comando | Sim. Modos de permissão, um modo de planejamento, um modelo classificador e política gerenciada pela organização. | Sim. Políticas de aprovação, regras por categoria e um agente revisor opcional. | Não documentado | Nenhuma. O ai-jail nunca vê comandos individuais e nunca pergunta. |
| Caminhos protegidos dentro do projeto | Sim. .git/hooks, .git/config, as configurações em .claude, .mcp.json, arquivos rc do shell e outros ficam somente leitura. | Sim. .git, .agents e .codex dentro das raízes graváveis ficam somente leitura. | Não documentado | Nenhum embutido. O projeto inteiro é gravável, .git/ incluído, e o git do lado do host confia no que encontra ali. Você mesmo mascara ou nega caminhos com --mask e deny_paths. Por que o .git/ importa. |
| Esconder segredos do agente e ainda assim usá-los | O mascaramento de credenciais consegue injetar o segredo real no proxy. Depende de uma configuração experimental. | Não documentado | Não documentado | Sim, desde a 2.2, com --secret KEY=host. O sandbox guarda um placeholder, e o proxy coloca o valor real só nas requisições para aquele único host. Cobre clientes que enviam HTTP puro ao proxy para esse host; túneis HTTPS não são tocados. Um arquivo mascarado continua sendo um arquivo vazio. |
| Plataformas | macOS, Linux, WSL2. Não roda em Windows nativo nem em WSL1. | macOS, Linux, WSL2 e Windows nativo. | Seatbelt no macOS, Docker ou Podman, gVisor, LXC (experimental) e Windows nativo. | Linux e macOS. No Windows, só com WSL2. |
| Instalação | Vem com o agente. No Linux precisa de bubblewrap e socat. | Vem com o agente. | Vem com o agente. Os backends de container precisam de Docker ou Podman. | Um binário separado. No Linux precisa de bubblewrap. |
Fontes: sandboxing do Claude Code, ambientes de sandbox do Claude Code, aprovações e segurança do Codex, permissões do Codex, sandbox de Linux do Codex, sandbox do Gemini CLI, sandbox de terminal do Antigravity, permissões do Antigravity, modelo de segurança do nono, README do zerobox.
Outros agentes, um card para cada
Use os dois
Um agente conhecido não precisa que você abra nada. O login dele é montado por padrão e o proxy filtrado libera o host da API do modelo, mais os registros de pacotes no Linux. Acrescente hosts com --allow-host, ou abra a rede inteira, quando uma ferramenta precisar de mais.
cd ~/Projects/my-appai-jail claudeai-jail --network claudeO ai-jail conhece o host da API de um agente conhecido e o libera por padrão, com os registries de pacotes no Linux. Uma lista explícita em --allow-host soma a esse padrão, então o host da API continua liberado. O login é montado por padrão; --no-agent-state dá uma execução sem login. Todas as flags estão em Configurar.
↔ Deslize para o lado para ver o diagrama inteiro
O que as checagens do agente continuam fazendo
Pedidos de permissão, regras de allow e deny e o modo de planejamento fazem parte do programa do agente, então funcionam dentro da jaula como funcionam fora. Eles pegam aquele comando que você não teria aprovado.
O que o ai-jail garante por baixo
O agente, seus servidores MCP e seus hooks nunca veem o seu diretório home, as suas chaves nem os tokens do seu shell, não importa o que você aprove. A única exceção é o login e a chave de API do próprio agente, montados por padrão para ele começar logado. O que o agente consegue ler, ele ainda consegue enviar para o host da própria API e para qualquer host que você liberou, então mascare os segredos dentro do projeto.
Docker, dev containers e máquinas virtuais
Essas também são boas respostas, e uma máquina virtual é uma resposta mais forte. Elas diferem no que você precisa montar e manter atualizado.
| O que você ganha | O que custa | |
|---|---|---|
| Container Docker | Sistema de arquivos, lista de processos e rede próprios. O agente vê só o que você monta. | Uma imagem para montar e manter, com as suas toolchains instaladas pela segunda vez. Se você montar o socket do Docker, o container equivale a root no host. |
| Dev container | O mesmo isolamento de um container, descrito num arquivo que o seu editor entende e o seu time pode compartilhar. | A mesma manutenção de imagem, mais um editor ou uma ferramenta que entenda o formato. |
| Máquina virtual | Um kernel próprio. É a fronteira mais forte desta lista, e a certa para código que você acredita ser hostil. | A opção mais pesada: um sistema guest para instalar e atualizar, que consome memória e para onde você precisa copiar o projeto. |
| ai-jail | Um sandbox em volta de um comando, usando os compiladores e runtimes que já estão na sua máquina. Não precisa de imagem, daemon nem root. | Ele compartilha o seu kernel, então um exploit de kernel ou de driver está fora da fronteira dele. É mais fraco que uma máquina virtual. |
A própria documentação do ai-jail o descreve como uma camada útil, que não substitui uma VM descartável. Leia o modelo de ameaças.
Para quem avalia: outros wrappers e plataformas
Dois wrappers open source e uma plataforma de runtime, cada um com suas fontes, para quem está pesando as alternativas.
Mostrar detalhes dos wrappers e das plataformas
Plataformas de runtime para agentes
O NVIDIA OpenShell é outra categoria: um gateway em execução que dá a cada agente o próprio container ou MicroVM, com um motor de políticas na frente da rede. O ai-jail é um processo que envolve um comando e termina junto com ele. Isto segue a documentação do OpenShell no momento em que este texto foi escrito, quando ele ainda estava antes da release 1.0.
| OpenShell | ai-jail | |
|---|---|---|
| O que roda o sandbox | Um daemon de gateway sobre Docker, Podman, Kubernetes ou KVM. O agente mora numa imagem de container que vem junto. | Só o binário. O agente roda no seu projeto com os compiladores e runtimes que já estão na sua máquina. |
| Rede | Negada por padrão. As regras casam programa, host e porta, com inspeção opcional de métodos, caminhos e ferramentas MCP. Um endpoint negado pode ser aprovado do lado do operador. | Desligada, filtrada por host ou aberta. O filtro é uma cerca de namespace mais um proxy CONNECT; ele vê hosts e portas, não o conteúdo, e um host permitido é confiável por inteiro. Uma porta do loopback do host repassada com --forward-port também é confiável por inteiro, sem regra nenhuma sobre ela. |
| Credenciais | Intermediadas pelo gateway e injetadas a cada requisição, nunca gravadas no disco do sandbox. | Ficam no ambiente. O login do próprio harness é montado por padrão, com leitura e escrita, e o que você passa com --env ou --env-from-file fica visível para tudo lá dentro; --no-agent-state dá uma execução sem login. Credenciais de ferramentas (--github, --aws, --kube, --gcloud, --docker-config) são montagens opt-in em somente leitura, e a documentação diz que somente leitura não impede o uso delas. |
| Teto de isolamento | Um driver de MicroVM dá uma fronteira de máquina virtual de verdade, e os sandboxes podem parar, reiniciar e manter o workspace. | Compartilha o seu kernel e roda uma vez só, por design. Para código hostil, a própria documentação manda usar uma VM descartável. |
| macOS | Roda dentro da VM Linux do Docker Desktop. O host macOS fica fora da política. | Perfis nativos do seatbelt gerados no host. |
| Telemetria e estabilidade | Telemetria anônima ligada por padrão, com opt-out. O formato de política ainda está mudando. | Sem telemetria. Cada versão nova continua lendo as configs que as versões antigas gravaram, e os testes garantem isso. Duas auditorias de código independentes em setembro de 2026, publicadas no repositório, levaram às correções da 2.4.0. |
A comparação no repositório do ai-jail, docs/openshell-comparison.md, é escrita nas duas direções e foi de onde saiu a allowlist de hosts.
Perguntas sobre usar os dois juntos
Devo desligar o sandbox e os pedidos de permissão do meu agente?
Mantenha os pedidos de permissão e as regras. Eles revisam comandos um a um, coisa que o ai-jail nunca faz. O sandbox de sistema operacional do agente é outra história no Linux: o ai-jail bloqueia as chamadas de sistema de que um sandbox bubblewrap aninhado precisa, e a documentação dele não diz que a combinação funciona. Se o agente avisar que o sandbox dele está indisponível dentro da jaula, a jaula continua lá.
O ai-jail é mais seguro que o Docker?
Os dois são a mesma classe de fronteira. Ambos compartilham o seu kernel, e nenhum é uma máquina virtual. O ai-jail começa com tudo fechado e não precisa de imagem, daemon nem root. Um container monta o que você mandar, e um socket do Docker montado equivale a root no host. Para código que você acredita ser hostil, use uma VM descartável.
Qual a diferença entre a allowlist de hosts e a dos próprios agentes?
Os proxies dos agentes são algo que o programa em sandbox precisa escolher usar. No ai-jail a cerca é o kernel: no Linux o sandbox mantém um network namespace privado cuja única saída é o proxy, e no macOS uma regra do seatbelt permite tráfego de saída só para a porta do proxy, então um programa que ignora o
http_proxy não alcança nada. Ele não cobre UDP, então o DNS dentro do sandbox falha no Linux e o resolver do sistema não fica cercado no macOS, e não inspeciona o conteúdo de uma conexão, então um host permitido é confiável por inteiro. Não combina com --network nem com --browser.Só uso o Claude Code. Ainda preciso do ai-jail?
Você tem três opções, no momento em que este texto foi escrito. O sandbox embutido cobre comandos de shell. O
@anthropic-ai/sandbox-runtime da Anthropic, um research preview em beta, envolve o processo inteiro. O ai-jail também envolve o processo inteiro, começa com o seu diretório home e as variáveis de ambiente fechados e usa a mesma política para qualquer outro agente que você testar depois. Veja a comparação de ambientes de sandbox da Anthropic.Coloque seu agente atrás das grades
O ai-jail é um binário único que não precisa de daemon nem de root. Você acrescenta uma palavra na frente do comando que já usa.
brew tap akitaonrails/tap && brew install ai-jailai-jail claude