TL;DR: jai is a free, open-source tool from Stanford that wraps any AI coding agent in a protective sandbox. Your project folder stays writable, but everything else on your system — your home directory, your SSH keys, your other projects — gets locked behind a read-only barrier. One command: jai claude. That's it. No Docker. No config files. No 45-minute setup process. If the AI does something catastrophic, it only affects a temporary layer that vanishes when you close the session.
Why AI Coders Need This
Here's a story you've probably heard by now — or lived through yourself.
You're building an app with an AI coding agent. You're in the flow. The agent is cranking out components, refactoring files, cleaning up your directory structure. Then you look up and realize your ~/.ssh directory is gone. Or your .env file with all your API keys just got overwritten with boilerplate. Or your entire node_modules and package-lock.json got nuked because the agent decided to "clean up" your project.
This is not hypothetical. In early 2026, reports started flooding in across Reddit, Hacker News, and developer forums. People were giving AI agents like Claude Code, Codex, and Cursor standard filesystem access — and those agents were accidentally destroying files, wiping directories, and making changes that couldn't be undone.
One post on Hacker News described an agent that emptied an entire working tree. Another reported a wiped home directory. These weren't malicious attacks — they were accidents. The AI was trying to help. It just made a bad call, the way any tool can, except this tool had permission to delete anything on your computer.
The core problem is simple: AI coding agents need access to your files to do their job, but giving them that access means trusting them not to break anything outside your project. And right now, most of them don't have guardrails for that.
Some tools have permission modes — Claude Code has its approval prompts, for example. But many vibe coders run agents in "yolo mode" or "full auto" because stopping to approve every single file write destroys the workflow. You either get the speed or you get the safety. Pick one.
That's the gap jai fills. You get both. The agent runs at full speed with full write access to your project, but it physically cannot touch anything else. Not because it chooses not to — because the operating system won't let it.
If you've been reading about AI sandbox security risks, jai is the practical answer to most of those concerns.
The Real Scenario: What Happens Without a Sandbox
Let's walk through a real situation that happens constantly to vibe coders.
You're building a Next.js app. You've been working on it for three days. The project is in ~/projects/my-saas-app/. You open your AI coding agent and type something like this:
Your prompt:
"Clean up this project. Remove any unused files, consolidate the config files, and restructure the components directory to use a feature-based architecture instead of the current flat structure."
Seems reasonable, right? You want a cleaner project. The agent starts working. It's moving files, deleting old components, rewriting imports. You're watching it go and feeling productive.
Then the agent decides that your tailwind.config.js at the project root is "redundant" because there's a reference to Tailwind in your package.json. It deletes the config. Then it sees your .env.local and decides to "consolidate" your environment variables into a single .env file — overwriting the one with your actual API keys. Then, for good measure, it "cleans up" some dotfiles it doesn't recognize: your .prettierrc, your .eslintrc, your .gitignore.
Twenty seconds. That's all it took. Your Tailwind config is gone. Your API keys are overwritten. Your linting setup is deleted. And if you were running in full auto mode, you didn't even get a chance to say no.
Now imagine the agent got really ambitious and started cleaning up files in your home directory. Your ~/.bashrc. Your ~/.gitconfig. Your SSH keys. That's the nightmare scenario — and it has happened to real people.
What jai Actually Does
jai is a single command you put in front of whatever AI agent you're running. Instead of:
claude
You type:
jai claude
That's the entire setup. No installation wizard. No config file. No Docker image to build. No 40-flag command to memorize.
When you run jai claude, here's what happens from your perspective:
- Your project folder stays fully writable. Whatever directory you're in when you run the command — that's your "safe zone." The AI agent can read, write, create, and delete files in there just like normal. Your project works exactly the way it always did.
- Your home directory becomes read-only (with a twist). The agent can still see your home directory files, but any changes it tries to make get captured in a temporary overlay. Think of it like a transparency sheet laid over a paper document — you can draw on the sheet all you want, but the paper underneath doesn't change.
- Everything else is locked down.
/tmpand/var/tmpget their own private copies. The rest of the filesystem is read-only. - When you exit, the overlay disappears. Any accidental changes the agent made outside your project folder just vanish. Your real files were never touched.
The effect is exactly what vibe coders need: the agent does its job in your project, and everything else on your computer is protected.
Understanding Each Part: The Three Modes
jai gives you three levels of protection. You pick the one that fits your situation.
Casual Mode (the default)
This is what most vibe coders will use day-to-day. Your home directory gets the copy-on-write overlay. The process runs as your user, so the agent can access your tools, your PATH, your shell config — it just can't permanently change them.
Best for: Normal coding sessions where you want the AI to have full context about your environment but can't permanently mess it up.
The tradeoff: The agent can read most of your files. It can see your .env files, your SSH keys, your browser data. It just can't change them. If you're worried about confidentiality (not just accidental damage), you want a stricter mode.
jai claude # casual mode (default)
jai codex # works with any agent
jai # just a sandboxed shell
Strict Mode
This creates a fully separate user identity. The AI agent runs as an unprivileged jai user with an empty home directory. It can't read your personal files at all — not your SSH keys, not your .env files, nothing.
Best for: Running agents you don't fully trust, testing unfamiliar tools, or working with code that might try to exfiltrate data.
The tradeoff: The agent loses access to your personal environment setup. Some tools might not work if they depend on configs in your home directory.
jai --strict claude
Bare Mode
A middle ground. The process runs as your user (so it can access your UID-based permissions), but your home directory is empty and private. You get integrity protection without the separate user identity.
Best for: Situations where strict mode breaks things because of UID requirements, but you still want the agent isolated from your home directory.
jai --bare claude
Quick Comparison
| Feature | Casual | Strict | Bare |
|---|---|---|---|
| Home directory | Copy-on-write overlay | Empty, private | Empty, private |
| Process runs as | Your user | Unprivileged jai user | Your user |
| Can read your files? | Yes (most) | No | No |
| Can change your files? | No (overlay catches it) | No | No |
| NFS home support | Yes | No | Yes |
For most vibe coders doing normal project work, casual mode is the right choice. It gives you the "seatbelt" without changing how anything works. Switch to strict mode when you're running something you don't trust — like a one-liner install script from a GitHub README you found at 2 AM.
What AI Gets Wrong About Sandboxing
If you ask an AI "how do I sandbox my coding agent," you'll usually get one of three answers — and all of them miss the point for vibe coders.
"Use Docker"
Docker is amazing for deployment. It's overkill for "I just want to ask Claude to fix a bug without risking my SSH keys." Docker requires you to build an image, write a Dockerfile, mount volumes, manage networking. By the time you've set all that up, you could have just fixed the bug yourself. jai is one command — no images, no Dockerfiles, no volume mounts.
"Use a VM"
Virtual machines are the gold standard for isolation. They're also slow to start, memory-hungry, and require you to maintain a separate operating system. For running a quick coding session? That's like renting a warehouse to store a single box.
"Just use the agent's permission system"
Permission systems are great when they work. The problem is they rely on the AI agent correctly predicting which operations are dangerous. An agent might ask for approval to delete a file but not realize that the "cleanup" command it's about to run will wipe a directory. And every permission prompt that interrupts your flow makes you more likely to start clicking "approve all" — which defeats the purpose entirely.
jai takes a different approach: it doesn't matter what the agent thinks it's doing. The operating system enforces the boundary. The agent can try to delete your home directory all day long — the overlay catches it, your real files are untouched, and the agent doesn't even know the difference.
This is the key insight that most AI-generated security advice misses: the best protection doesn't depend on the AI being smart about safety. It works even when the AI is being dumb.
If you want to go deeper on reviewing what AI agents are actually doing to your codebase, check out our guide on how to review AI-generated code for security issues.
How to Debug: When Things Don't Work Inside jai
jai is designed to be invisible — your agent should work exactly the same way inside the sandbox as outside it. But sometimes things break. Here's how to troubleshoot the common issues.
"My agent can't find my config files"
If you're in strict or bare mode, your home directory is empty. The agent can't see your .npmrc, .gitconfig, or any other dotfiles. You have two options:
- Switch to casual mode — it lets the agent read (but not permanently modify) your home directory.
- Copy needed configs into your project directory — put a local
.npmrcor.gitconfigin the project root before starting the jai session.
"Files I created disappeared after exiting"
This is jai working as intended. Files created in your project directory (the folder you were in when you ran jai) persist on your real filesystem. Files created anywhere else — like in your home directory or /tmp — go to the overlay and vanish when the session ends.
The fix: Make sure you cd into your project directory before running jai. Whatever directory you're in becomes the writable zone.
"npm install / pip install isn't working"
Package managers sometimes need to write to global directories or cache locations in your home directory. In casual mode, these writes go to the overlay and work fine during the session (they just don't persist). In strict/bare mode, the empty home directory might confuse some tools.
The fix: For most cases, casual mode handles this transparently. If you're in strict mode and hitting issues, try running with --bare instead, which keeps your UID while still protecting your home directory.
"I want to keep the changes the agent made outside my project"
Sometimes the agent installs a useful tool globally or modifies a config file you actually want to keep. Since those changes are in the overlay, they'll disappear when you exit.
The fix: Before exiting the jai session, copy any files you want to keep back into your project directory. After exiting, move them to their proper locations. Yes, it's an extra step — but that's the tradeoff for safety.
"jai says it needs root/sudo"
jai uses Linux namespaces to create the sandbox, and some operations require elevated privileges to set up the namespace. On most modern Linux systems, unprivileged user namespaces are enabled by default. If yours are disabled, you may need to enable them or run jai with sudo for the initial setup.
Check your system:
cat /proc/sys/kernel/unprivileged_userns_clone
If it returns 0, you'll need to enable it:
sudo sysctl -w kernel.unprivileged_userns_clone=1
What's Next: The Future of AI Agent Sandboxing
jai solves an immediate, urgent problem — but it's also a sign of where the entire AI coding ecosystem is heading.
Right now, we're in the "wild west" phase of AI-assisted development. Agents have broad filesystem access, minimal containment, and most vibe coders are running them with full trust because the alternative (manually approving every file operation) is too slow. That's not sustainable.
Here's what to expect over the next 12 months:
Agent tools will build sandboxing in
The major AI coding tools — Claude Code, Cursor, Windsurf, Codex — will start shipping with built-in containment. Some already have permission systems, but expect these to evolve into proper filesystem isolation that doesn't require user configuration. jai is proving the demand exists.
The "principle of least privilege" is coming to AI
Just like web browsers eventually got sandboxed tabs, and mobile apps got permission systems, AI agents will get fine-grained access controls. Instead of "this agent can access everything" or "this agent can access nothing," you'll define scopes: "this agent can modify files in ~/projects/my-app/ and read (but not write) my .gitconfig."
Damage recovery will get better
Tools like Git already give you a safety net if your code is committed. But jai-style overlay filesystems point toward a future where every AI agent session is automatically snapshotted. Made a mess? Roll back the entire session with one command.
What you should do right now
- If you're on Linux: Install jai and start using it today. It's free, it's from Stanford, and it takes 30 seconds to set up. Visit jai.scs.stanford.edu for installation instructions.
- If you're on macOS or Windows: jai doesn't work on your OS yet (it needs Linux namespaces). In the meantime, keep your AI agents out of yolo/full-auto mode, commit your code frequently, and review what the agent is doing before you approve destructive operations.
- Either way: Start thinking about AI agent access the same way you think about app permissions on your phone. Just because an agent could have access to your entire filesystem doesn't mean it should.
For a broader look at how to think about security when you're building with AI tools, start with our AI sandbox security risks guide and the vibe coding security checklist.
Frequently Asked Questions
Does jai work on macOS or Windows?
Not yet. jai relies on Linux-specific features — namespaces and overlayfs — to create the sandbox. If you're on macOS, you'd need to run it inside a Linux virtual machine. On Windows, WSL2 (Windows Subsystem for Linux) may work since it runs a real Linux kernel. The jai team may add broader OS support in the future, but as of March 2026, it's Linux only.
Is jai a replacement for Docker?
No, and it's not trying to be. Docker is for reproducible, image-based environments — it's the right choice for deployment, CI/CD pipelines, and complex multi-service architectures. jai is for quick, ad-hoc sandboxing when you just want to run an AI agent without risking your files. Think of jai as a seatbelt and Docker as a roll cage. Both keep you safe, but you wouldn't install a roll cage just to drive to the grocery store.
Can AI agents escape the jai sandbox?
jai is honest about its limitations — it's a "casual sandbox" designed to reduce the blast radius, not provide military-grade isolation. In casual mode, the agent can still read your files (it just can't permanently change them). Even strict mode isn't equivalent to a hardened container runtime or VM. For protecting production secrets or defending against deliberately malicious code, use a proper container or virtual machine. But for the everyday scenario of "my AI agent accidentally deleted something it shouldn't have" — jai catches that.
Does jai slow down my AI agent?
No. jai uses Linux namespaces — the same underlying technology that powers Docker containers. The performance overhead is essentially zero. Your agent runs at full speed. The only difference is that writes outside your project directory go to a temporary overlay instead of your real filesystem, and that operation adds negligible latency.
What happens to files the AI creates inside jai?
It depends on where the files are created. Files in your current working directory (the project folder you launched jai from) are written to your real filesystem — they persist after the session ends. Files created elsewhere — your home directory, /tmp, global install paths — go to the temporary overlay and disappear when you exit jai. Your project gets the changes. Your system stays clean.