You use more than one agent
ai-jail: one policy file, any command, the whole process inside. Install.
Compare
Your agent already has a sandbox. It covers a different half.
Built-in sandboxes and permission prompts watch the commands the model runs. ai-jail decides what the whole agent program can see on your machine, and it is tuned for a trusted agent's mistakes. The two work together.
For someone choosing between tools. The six situations at the top answer most questions.
Last reviewed October 15, 2026. Other products change quickly, so every claim about them links to the vendor's own documentation.
In short
Six situations, one answer each. The rest of the page shows the evidence.
You only use Claude Code
Anthropic's own sandbox-runtime wraps the whole process too, in beta; ai-jail adds an empty home and a closed network. See the cards.
You want the agent's own sandbox and prompts
Keep them on. They work inside ai-jail. Use both.
You want policies per tool, approvals at runtime and a signed audit trail
nono goes further there, at the cost of a policy language and a supervisor. Compare the wrappers.
You sandbox from code, one tool call at a time
zerobox has SDKs for that; it leaves reads open and has had no release since May 2026. Compare the wrappers.
You do not trust the code at all
A disposable virtual machine. Every tool on this page shares your kernel. Docker, containers and VMs.
Where the wall is
At the time of writing, Claude Code's sandbox applies to shell commands and their child processes. Its file tools use the permission system instead, and its documentation says MCP servers and hooks run unconstrained on the host. ai-jail starts the agent itself inside the wall, so everything it launches is inside too.
↔ Swipe sideways to see the full diagram
Codex also sandboxes the commands it spawns and leaves the codex process outside. Its documentation says MCP servers use their own process or transport, outside the sandbox.
A permission prompt is a different kind of protection
A prompt asks a person, and a person can be rushed or fooled. A sandbox asks the kernel, which gives the same answer every time.
↔ Swipe sideways to see the full diagram
Modes that take the person out
At the time of writing, each of these agents has a mode that stops asking. When the prompt is gone, the sandbox is the only protection left, if one is on.
| Agent | Mode | What the vendor says it does |
|---|---|---|
| Claude Code | auto | Everything runs and a second model reviews actions in your place. The documentation calls this classifier a per-action control, not an isolation boundary. |
| Claude Code | bypassPermissions, also --dangerously-skip-permissions | Everything runs with no checks. The documentation says to use it in isolated containers and VMs only. |
| Codex CLI | Approval policy never | The agent never asks. The sandbox mode still applies. See approvals and security. |
| Codex CLI | danger-full-access, or --yolo | The sandbox is off. With --yolo there are no approvals either. |
Side by side
Everything here describes each product's documentation at the time of writing. Where the documentation we read does not answer a question, the cell says so.
| Claude Code sandbox | Codex CLI sandbox | Gemini CLI sandbox | ai-jail | |
|---|---|---|---|---|
| What a wrapper around the whole agent adds | ||||
| What is inside the wall | Bash, PowerShell and Monitor commands and their children. The claude process, its file tools, MCP servers and hooks are outside. | The commands the agent spawns. The codex process is outside. The documentation says local and remote MCP servers use their own process or transport, so they are outside too. | The whole CLI process, or only the shell and write tools with security.toolSandboxing. | The whole process tree: the agent, its file tools, MCP servers, hooks and every command. |
| On by default | No. You turn it on with /sandbox or sandbox.enabled. If a dependency is missing it warns and runs commands unsandboxed, unless you set sandbox.failIfUnavailable. | Yes. workspace-write is the default mode. | You turn it on with -s, GEMINI_SANDBOX or tools.sandbox. | It is on whenever you start the agent through it. If the configuration is invalid it refuses to start. |
Can sandboxed code read ~/.ssh by default? | Yes. The documentation says the default still allows reading credential files such as ~/.aws/credentials and ~/.ssh/. Deny rules are opt-in. | Yes on Linux, where the whole filesystem is mounted read only. A permission profile can add deny rules for paths such as **/.env*, and OpenAI's own hardened configuration does. macOS default: not documented. | The default macOS profile, permissive-open, allows broad file reads. Stricter profiles are opt-in. | No. The agent gets a fresh, empty home directory. --ssh is an opt-in. |
| Environment variables | Sandboxed commands inherit the parent environment by default, credentials included. sandbox.credentials can deny or mask them. | Not documented | Not documented | A minimal allowlist of terminal, locale and toolchain variables, plus the invoked harness's own API key, copied by default with its login; --no-agent-state stops it. You add others by name with --env. |
| Escape hatch the model can use | The model may retry a command with dangerouslyDisableSandbox, which goes through the normal permission flow. allowUnsandboxedCommands: false turns that off. | With the on-request policy the agent asks to leave the sandbox for edits outside the workspace or for network. | Not documented | None. You set the policy before the agent starts, and a project's own .ai-jail file can tighten it but never open it. |
| Works with every agent | Claude Code only | Codex only | Gemini CLI only | Any command, with one policy file for all of your agents. |
| Network model | A proxy with a per-domain allowlist. A new domain prompts you, and each command still gets its own approval. The documentation notes that the proxy trusts the hostname the client sends, so domain fronting can bypass it. | Off by default in workspace-write. One setting turns it on, and an optional proxy adds per-domain allow and deny rules. The documentation says the proxy does not filter MCP server connections, web search or the browser. | The default profile allows network. Stricter and proxied profiles are opt-in. | Three modes. The default is closed except a known agent's own API host on both platforms and, on Linux with toolchains on, a fixed list of package registries that includes github.com, so git clone over HTTPS works; --no-network closes both. --allow-host adds hosts and their subdomains, enforced by the network namespace on Linux or a seatbelt endpoint rule on macOS, through a proxy that resolves each name once and dials the address it checked. --network opens everything. The filter is TCP only, has no per-path rules and never prompts: a host outside the list is denied and --audit-log records the attempt. An allowed host is trusted wholesale. On Linux, --forward-port relays one port of the host's loopback into the sandbox, with no rule on what passes. |
| What the built-in sandboxes do better | ||||
| Approval for each command | Yes. Permission modes, a plan mode, a classifier model and managed organization policy. | Yes. Approval policies, per-category rules and an optional reviewer agent. | Not documented | None. ai-jail never sees individual commands and never asks. |
| Protected paths inside the project | Yes. .git/hooks, .git/config, .claude settings, .mcp.json, shell rc files and more stay read only. | Yes. .git, .agents and .codex under writable roots are read only. | Not documented | None built in. The whole project is writable, .git/ included, and host-side git trusts what it finds there. You mask or deny paths yourself with --mask and deny_paths. Why .git/ matters. |
| Hiding secrets from the agent while still using them | Credential masking can inject the real secret at the proxy. It needs an experimental setting. | Not documented | Not documented | Yes, since 2.2, with --secret KEY=host. The sandbox holds a placeholder and the proxy puts the real value only into requests to that one host. It covers clients that send plain HTTP to the proxy for that host; HTTPS tunnels are not touched. A masked file stays an empty file. |
| Platforms | macOS, Linux, WSL2. Not native Windows or WSL1. | macOS, Linux, WSL2 and native Windows. | macOS Seatbelt, Docker or Podman, gVisor, LXC (experimental) and native Windows. | Linux and macOS. On Windows, WSL2 only. |
| Install | Ships with the agent. On Linux it needs bubblewrap and socat. | Ships with the agent. | Ships with the agent. The container backends need Docker or Podman. | A separate binary. On Linux it needs bubblewrap. |
Sources: Claude Code sandboxing, Claude Code sandbox environments, Codex approvals and security, Codex permissions, Codex Linux sandbox, Gemini CLI sandbox, Antigravity terminal sandbox, Antigravity permissions, nono security model, zerobox README.
Other agents, one card each
Use both
A known agent needs nothing opened. Its login is mounted by default and the filtered proxy lets through its model API host, plus package registries on Linux. Add hosts with --allow-host, or open the whole network, when a tool needs more.
cd ~/Projects/my-appai-jail claudeai-jail --network claudeai-jail knows a known agent's own API host and allows it by default, with the package registries on Linux. An explicit --allow-host list adds to that default, so the API host stays allowed. The login is mounted by default; --no-agent-state gives a logged-out run. Every flag is on Configure.
↔ Swipe sideways to see the full diagram
What the agent's own checks still do
Permission prompts, allow and deny rules and plan mode are part of the agent program, so they work inside the jail as they do outside. They catch the command you would not have approved.
What ai-jail guarantees underneath
The agent, its MCP servers and its hooks never see your home directory, your keys or the tokens in your shell, whatever you approve. The one exception is the agent's own login and API key, mounted by default so it starts signed in. What the agent can read, it can still send to its own API host and to any host you allowed, so mask the secrets inside the project.
Docker, dev containers and virtual machines
These are good answers too, and a virtual machine is a stronger one. They differ in what you have to build and keep up to date.
| What it gives you | What it costs | |
|---|---|---|
| Docker container | Its own filesystem, process list and network. The agent sees only what you mount. | An image to build and maintain, with your toolchains installed a second time. If you mount the Docker socket, the container is root-equivalent on the host. |
| Dev container | The same isolation as a container, described in a file your editor understands and your team can share. | The same image upkeep, plus an editor or tool that understands the format. |
| Virtual machine | Its own kernel. It is the strongest boundary here, and the right one for code you believe is hostile. | The heaviest option: a guest system to install, update, give memory to and copy your project into. |
| ai-jail | A sandbox around one command, using the compilers and runtimes already on your machine. It needs no image, daemon or root. | It shares your kernel, so a kernel or driver exploit is outside its boundary. It is weaker than a virtual machine. |
ai-jail's own documentation calls it a useful layer, not a replacement for a disposable VM. Read the threat model.
For evaluators: other wrappers and platforms
Two open source wrappers and one runtime platform, each with its sources, for anyone weighing the alternatives.
Show wrapper and platform details
Agent runtime platforms
NVIDIA OpenShell is a different category: a running gateway that gives each agent its own container or MicroVM, with a policy engine in front of the network. ai-jail is one process that wraps one command and exits with it. This follows OpenShell's documentation at the time of writing, when it was still before its 1.0 release.
| OpenShell | ai-jail | |
|---|---|---|
| What runs the sandbox | A gateway daemon on Docker, Podman, Kubernetes or KVM. The agent lives in a bundled container image. | Nothing but the binary. The agent runs against your project with the compilers and runtimes already on your machine. |
| Network | Deny by default. Rules match program, host and port, with optional inspection of methods, paths and MCP tools. A denied endpoint can be approved from the operator's side. | Off, filtered by host, or open. The filter is a namespace fence and a CONNECT proxy; it sees hosts and ports but not content, and an allowed host is trusted wholesale. A host loopback port relayed with --forward-port is trusted whole as well, with no rule on it. |
| Credentials | Brokered by the gateway and injected per request, never written to the sandbox disk. | Ambient. The harness's own login is mounted by default, read-write, and what you pass with --env or --env-from-file is visible to everything inside; --no-agent-state gives a logged-out run. Tool credentials (--github, --aws, --kube, --gcloud, --docker-config) are opt-in read-only mounts, and the documentation says read-only does not stop their use. |
| Isolation ceiling | A MicroVM driver gives a real virtual machine boundary, and sandboxes can stop, restart and keep their workspace. | Shares your kernel and is one-shot by design. For hostile code its own documentation says to use a disposable VM. |
| macOS | Runs inside the Docker Desktop Linux VM. The macOS host is outside the policy. | Native seatbelt profiles generated on the host. |
| Telemetry and stability | Anonymous telemetry on by default with an opt-out. The policy format is still changing. | No telemetry. Every new version keeps reading the configs older versions wrote, and tests enforce it. Two independent source audits in September 2026, published in the repository, led to the fixes in 2.4.0. |
The comparison in ai-jail's repository, docs/openshell-comparison.md, is written in both directions and is where the host allowlist came from.
Questions about running them together
Should I turn off my agent's own sandbox and prompts?
Keep the prompts and rules. They review single commands, which ai-jail never does. The agent's OS sandbox is a different matter on Linux: ai-jail blocks the system calls a nested bubblewrap sandbox needs, and its documentation does not say the combination works. If the agent reports that its sandbox is unavailable inside the jail, the jail is still there.
Is ai-jail safer than Docker?
They are the same class of boundary. Both share your kernel, and neither is a virtual machine. ai-jail starts with everything closed and needs no image, no daemon and no root. A container mounts what you tell it to, and a mounted Docker socket is root-equivalent on the host. For code you believe is hostile, use a disposable VM.
How does the host allowlist differ from the agents' own?
The agents' proxies are something the sandboxed program has to choose to use. In ai-jail the fence is the kernel: on Linux the sandbox keeps a private network namespace whose only exit is the proxy, and on macOS a seatbelt rule allows outbound traffic to the proxy's port alone, so a program that ignores
http_proxy reaches nothing. It does not cover UDP, so DNS inside the sandbox fails on Linux and the system resolver is not fenced on macOS, and it does not inspect the content of a connection, so an allowed host is trusted wholesale. It cannot combine with --network or --browser.I only use Claude Code. Do I still need ai-jail?
You have three options, at the time of writing. The built-in sandbox covers shell commands. Anthropic's
@anthropic-ai/sandbox-runtime, a beta research preview, wraps the whole process. ai-jail wraps the whole process too, starts with your home directory and environment variables closed, and uses the same policy for any other agent you try later. See Anthropic's comparison of sandbox environments.Put your agent behind bars
ai-jail is a single binary that needs no daemon and no root. You add one word in front of the command you already run.
brew tap akitaonrails/tap && brew install ai-jailai-jail claude