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. Os dois funcionam juntos.

Instalar Como funciona

Última revisão em 21 de setembro 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.

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.

Dois painéis. À esquerda, um sandbox embutido cerca só os comandos de shell, enquanto o agente, seus servidores MCP e seus hooks ficam fora do muro, com linhas que chegam ao seu diretório home. À direita, o ai-jail cerca o agente, os servidores MCP, os hooks, os comandos de shell e o projeto juntos, e o seu diretório home fica do lado de fora, apagado e gradeado. — O painel da esquerda segue a documentação do Claude Code.

O Codex também coloca em sandbox os comandos que dispara e deixa o processo codex do lado de fora. A documentação dele não diz onde rodam os servidores MCP locais.

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.

Dois painéis. À esquerda, uma linha que sai do agente atravessa uma pilha de diálogos de aprovação com um botão Aprovar e chega às suas chaves. À direita, a mesma linha para num muro com o rótulo regra do kernel, e as suas chaves atrás dele aparecem apagadas e gradeadas. — Os pedidos de permissão são úteis. Eles são uma etapa de revisão, e um sandbox é uma fronteira.

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.

O que um wrapper em volta do agente inteiro acrescenta
	Sandbox do Claude Code	Sandbox do Codex CLI	Sandbox do Gemini CLI	ai-jail
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. Servidores MCP locais: não documentado.	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. As entradas de negação são opt-in. 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. 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.
O que os sandboxes embutidos fazem melhor
Modelo de rede	Um proxy com allowlist por domínio. Um domínio novo gera um pedido de permissão. A documentação observa que 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.	O perfil padrão permite rede. Perfis mais restritos e com proxy são opt-in.	Tudo ou nada. Fica desligada por padrão, e `--network` abre tudo. Não há filtro por domínio, de propósito.
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. Você mesmo mascara ou nega caminhos com `--mask` e `deny_paths`.
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	Não. Um arquivo mascarado é 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, sandbox de Linux do Codex, sandbox do Gemini CLI.

Use os dois

Com a rede desligada, um agente em nuvem não alcança a API do próprio modelo. Na prática você abre duas coisas: a rede e o login do agente.

um agente em nuvem na jaula

cd ~/Projects/my-appai-jail --network --agent-state claude

Um muro grande com o rótulo ai-jail cerca o agente, seus servidores MCP, seus hooks, o projeto e seus comandos de shell. Entre o agente e os comandos de shell fica o pedido de aprovação do próprio agente. Uma linha sai do muro por um portão até a API do modelo. O seu diretório home fica do lado de fora do muro, apagado e gradeado. — O muro externo é o ai-jail. Dentro dele, os pedidos de permissão e as regras do agente continuam fazendo o trabalho deles.

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. O que o agente consegue ler, ele ainda consegue enviar, 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.

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.

Por que não existe uma allowlist de rede por domínio?

Um filtro que mora dentro do sandbox é um filtro que o agente pode simplesmente não usar. O mantenedor fechou o pedido como fora de escopo: uma versão sem root precisa de uma pilha de rede em userspace e de inspeção de SNI, que falha quando o SNI está ausente ou criptografado, ou então de interceptação TLS do tráfego de API do agente, que carrega credenciais. Filtre onde o privilégio já existe: uma regra de nftables para o uid do agente, um slice do systemd com IPAddressAllow=, ou um container ou VM que seja dono do network namespace.

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.

terminal

brew tap akitaonrails/tap && brew install ai-jailai-jail claude

Instalar o ai-jail Ver no GitHub