HN follow-up on Stanford's jai sandbox emphasized that agent changes persist under .jai by default, with explicit mounts back into the real home directory when needed. That clarification matters for teams comparing dev containers, bubblewrap, podman, and LXC, so they can decide how much host state an agent should be allowed to keep or touch.
Posted by mazieres
jai is a lightweight Linux sandbox tool from Stanford Secure Computer Systems for safely running AI agents. It provides effortless containment with one command, offering full access to the working directory, copy-on-write overlay or private home directory, private temps, and read-only rest of filesystem. Features three modes (Casual, Strict, Bare) balancing isolation levels. Addresses risks like file deletion from AI tools without needing Docker or VMs.
The new detail is not jai's existence but where agent changes actually live. The product page in the launch page describes a sandbox with full access to the working directory, a copy-on-write overlay or private home directory, private temp space, and a read-only rest of the filesystem. The follow-up in the HN thread clarified that these changes are persistent under "$HOME/.jai" by default, with explicit mounts for chosen directories back into the real home directory.
That matters because it makes jai less like a disposable session wrapper and more like a bounded persistence layer for coding agents. In the discussion recap, Mazières said teams should still use dev containers when they can, and framed jai as the option that "just works in every single scenario" when developers drift out of strict container workflows.
Posted by mazieres
Today's new discussion is mostly clarification and deployment advice from the author plus a few implementation comparisons. The author explains that jai keeps changes persistent under `$HOME/.jai` by default, but you can explicitly persist selected directories into your real home directory, and they strongly recommend dev containers when possible—jai is for the cases where users are inconsistent about staying inside containers. There’s also a new comparison point from commenters: one notes a similar earlier effort that settled on bubblewrap, another says they use LXC for their homelab workflow, and another argues the bigger issue is accidental destructive commands from a helpful agent, not just hostile behavior. Overall, the new signal is about where jai fits in an ecosystem of isolation tools and how much real-world risk is from mistakes versus malicious output.
The thread also sharpened the comparison set. Commenters pointed to bubblewrap and LXC as alternative containment approaches, but the practical question stayed the same: how much host state should an agent retain, and how much of the real filesystem should it be allowed to touch. One commenter in fresh discussion said the main threat is a helpful assistant "fat fingering something," which is exactly the failure mode jai is trying to narrow.
Posted by mazieres
If you build or operate AI coding tools, the thread is about practical containment choices: jai’s one-command sandboxing, persistence model, and how it compares with dev containers, bubblewrap, podman, LXC, and separate-user approaches. The useful takeaway is that the discussion is less about model behavior and more about safe execution boundaries and how changes get back into the real filesystem.
Posted by mazieres
Thread discussion highlights: - mazieres on filesystem persistence: jai uses persistent file systems for your changes ... stored under `$HOME/.jai` by default ... expose specific directories to persist state in your home directory - mazieres on dev container guidance: Please use a dev container! ... if you aren't 100% consistent about using a container, then jai may be for you, because it just works in every single scenario. - afzalive on bubblewrap and LXC alternatives: Someone tried this earlier this year but they ended up going with bubblewrap ... I ended up creating an LXC on my homelab...
