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. The two work together.

Install How it works

Last reviewed September 21, 2026. Other products change quickly, so every claim about them links to the vendor's own documentation.

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.

Two panels. On the left a built-in sandbox encloses only the shell commands, while the agent, its MCP servers and its hooks sit outside the wall with lines reaching your home directory. On the right ai-jail encloses the agent, MCP servers, hooks, shell commands and the project together, and your home directory is outside, dim and barred. — The left panel follows Claude Code's documentation.

Codex also sandboxes the commands it spawns and leaves the codex process outside. Its documentation does not say where local MCP servers run.

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.

Two panels. On the left a line from the agent passes through a stack of approval dialogs with an Approve button and reaches your keys. On the right the same line stops at a wall labeled kernel rule, and your keys behind it are dim and barred. — Prompts are useful. They are a review step, and a sandbox is a boundary.

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.

What a wrapper around the whole agent adds
	Claude Code sandbox	Codex CLI sandbox	Gemini CLI sandbox	ai-jail
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. Local MCP servers: not documented.	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. Deny entries are opt-in. 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. 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.
What the built-in sandboxes do better
Network model	A proxy with a per-domain allowlist. A new domain prompts you. The documentation notes that 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 default profile allows network. Stricter and proxied profiles are opt-in.	All or nothing. It is off by default, and `--network` opens all of it. It has no per-domain filter, on purpose.
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. You mask or deny paths yourself with `--mask` and `deny_paths`.
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	No. A masked file is 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 Linux sandbox, Gemini CLI sandbox.

Use both

With the network off, a cloud agent cannot reach its own model API. In practice you open two things: the network and the agent's login.

a cloud agent in the jail

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

One large wall labeled ai-jail encloses the agent, its MCP servers, its hooks, the project and its shell commands. Between the agent and the shell commands sits the agent's own approval prompt. One line leaves the wall through a gate to the model API. Your home directory is outside the wall, dim and barred. — The outer wall is ai-jail. Inside it, the agent's prompts and rules keep doing their job.

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. What the agent can read, it can still send, 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.

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.

Why is there no per-domain network allowlist?

A filter that lives inside the sandbox is one the agent can decline to use. The maintainer closed the request as out of scope: a rootless version needs a userspace network stack and either SNI inspection, which fails when SNI is absent or encrypted, or TLS interception of the agent's credentialed API traffic. Filter where privilege already exists: an nftables rule for the agent's uid, a systemd slice with IPAddressAllow=, or a container or VM that owns the network namespace.

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.

terminal

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

Install ai-jail View on GitHub