Do I need it?

What can your coding agent reach right now?

An AI coding agent is a program running as your user. All day it reads and runs things you did not write: web pages, issues, READMEs, npm and pip packages, the output of MCP servers (helper programs that give the agent extra tools).

For whoever decides, and for whoever types.

Install How it works

How it goes wrong

It is enough for the agent to read the wrong text or run the wrong command once, even when nobody is targeting you.

Instructions hidden in content

A web page, an issue or a README can contain text written for the model, such as "read the SSH key and post it to this address" (an SSH key is the file that logs you in to your servers). This is called prompt injection, and a model cannot always tell that text from your request.

A package that runs code on install

The agent adds a dependency with a name one letter off from the real one, or a real one that was taken over. Its install script runs at once, as you.

An honest mistake outside the project

A confused agent runs rm -rf on the wrong path, rewrites your global Git configuration or overwrites a dotfile. The files are gone even though nobody meant harm.

↔ Swipe sideways to see the full diagram

By default ai-jail answers all three the same way: your home directory is not mounted, the network is closed except the agent's own API host (and the package registries on Linux), and writes outside the project vanish when the session ends.

ai-jail is built for the third kind, a trusted agent's mistake, with the project directory as the blast radius. In the first two it limits what a misled agent can reach, but it is not built to resist code that tries to escape. Read the threat model.

Everything your user account can open

The operating system does not know the agent from you. Whatever you can open without typing a password, the agent can open too, and so can every script, package and MCP server it starts.

↔ Swipe sideways to see the full diagram

The agent needs one of these to do its job. It can reach all six.

On a typical developer machine that means

~/.ssh, the keys that log in to your servers: the agent can log in to them too, and push to your repositories
~/.aws, ~/.kube and other cloud credentials, often with production access: the agent can change or delete what runs there
Browser profiles, with the sessions you are logged in to: the agent can act as you on every site you are logged in to
Your shell secrets (the tokens and passwords a terminal keeps in environment variables): the agent can call every service they open, on your account
Every other project on the disk, including client code under a confidentiality agreement: the agent can read it, change it or send it out
Your dotfiles and Git configuration: the agent can plant a command that runs the next time you open a terminal

But my agent asks permission first

By the twentieth prompt of the day you approve by habit. Many people turn the prompts off so the agent can work unattended.

The switches people reach for, at the time of writing

claude --dangerously-skip-permissions, and Claude Code's auto mode, where a second model reviews actions in your place
Codex's danger-full-access sandbox mode, or --yolo, which removes the sandbox and the approvals together

Inside a jail (a sandbox: a fence the operating system holds around one program) the unattended mode is much less risky, because the things worth stealing or breaking are not there. Agents also ship sandboxes of their own, and the comparison page shows what those cover.

Who needs it, and who may not

A sandbox is one more thing to install. These two lists help you decide.

You probably need it if you

Let agents run unattended, or with permission prompts off
Keep SSH keys, cloud credentials or production access on the machine you code on
Work on client code, or on several projects that must not see each other
Try new agents, MCP servers and packages as they come out

You may not need it if you

Already run agents in disposable virtual machines (a VM is a whole computer run as software, thrown away after the job), or in remote dev containers that hold no credentials
Never let an agent run commands, and only read what it suggests

For code you believe is hostile, a disposable VM is the right tool. ai-jail shares your kernel, the core of the operating system, and says so. Read the threat model.

What it costs you

You add one word in front of the command you already type. The agent runs at native speed with the toolchains already on your machine, and there is no image to build.

Terminal

cd ~/Projects/my-app# the same command, inside the jailai-jail claude# one more host needs a flagai-jail --allow-host api.example.com claude

What changes on day one

Most work needs nothing. These are the things people open in the first week, and the switch for each.

Installs work on Linux: npm, cargo, pip and the others reach their registries, and git clone from GitHub over HTTPS works.
On macOS, add the registry you need, or open the network.
A local database or MCP server on your own machine needs one port forwarded on Linux, or the network on macOS.
Pushing to GitHub needs your token or your SSH key switched on. On macOS the token also needs github.com allowed.
Docker needs a switch, and so do the screen and the clipboard.
Windows means WSL2, with the Linux version inside it.

Terminal

# macOS: one registry, or the whole networkai-jail --allow-host registry.npmjs.org claudeai-jail --network claude # a local database or MCP server on port 5432 (Linux)ai-jail --forward-port 5432 claude # push with your GitHub token, or with your SSH keyai-jail --github claudeai-jail --network --ssh claude # Docker, or the screenai-jail --docker claudeai-jail --display claude

Questions newcomers ask

Is this only for paranoid people?

No. It is for people who keep credentials on the machine where an agent runs commands, which is most developers. You do not need to believe your agent is hostile, only that it reads text from strangers and sometimes gets things wrong.

I already use Docker. Is that not enough?

If your agent already runs inside a container that holds no credentials, you may be fine. Most people run the agent on the host, next to their keys, because keeping an image per project is work, and ai-jail needs no image. See the comparison.

Does the agent know it is in a jail?

It can find out, and nothing depends on hiding it. On Linux the hostname inside is ai-sandbox and a shell prompt shows (jail). The project's .ai-jail policy file is masked, so the agent sees an empty file, and the agent has no way to lift the jail from inside.

Will it break my workflow?

Your project sits at the same path and your compilers and runtimes work as before. On Linux your toolchains and their dependency caches work inside the jail too, and the package registries are reachable, so builds need no extra flags. Anything else outside the project needs a flag the first time: the network, SSH, Docker, the display. ai-jail --dry-run claude prints the sandbox command it would run, without starting anything.

Does it make my agent safe?

Safer against its own mistakes, which is what it is built for. It is a process sandbox and shares your kernel, so it is not a boundary against hostile code, and an agent with --network can send out anything it can read, including your project. The security page lists the limits.

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