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 tools.

Install How it works

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.

A cyan agent chip in the middle with lines running to six open tiles around it: SSH keys, cloud credentials, browser profiles, shell tokens, other projects and your project. Nothing is walled off. — 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 and push to your repositories
~/.aws, ~/.kube and other cloud credentials, often with production access
Browser profiles, with the sessions you are logged in to
API keys and tokens exported in your shell environment
Every other project on the disk, including client code under a confidentiality agreement
Your dotfiles and Git configuration, which run or apply the next time you open a terminal

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". 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.

Two rows. Without a jail, a poisoned page reaches the agent, the agent reads the SSH key and sends it to the internet. With ai-jail, the agent sits inside a wall of bars, no arrow leaves it, and the SSH key and the internet are dim and barred outside. — By default ai-jail answers all three the same way: your home directory is not mounted, the network is off, and writes outside the project vanish when the session ends.

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 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, 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 virtual machine is the right tool. ai-jail shares your kernel 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# a cloud agent needs the network and its own loginai-jail --network --agent-state 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. Anything outside the project needs a flag the first time: the network, the agent's login, 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. It is a process sandbox that shares your kernel, so a kernel exploit is outside its boundary, 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