mazieres

An AI agent that works 99.9% of the time is a lot more dangerous than one that works 90% of the time, because the former leads to expectations of 100% safe behavior. I've never been saved from harm by a car seatbelt. Should I extrapolate that vehicles are basically safe and seatbelts are safety theater?

Please use a dev container! Empirically, a lot of people don't, and some people regularly enable YOLO mode on their actual laptops. So if you've never run a code assistant outside of a dev container, that's fantastic and I don't want to change your behavior. But be honest with yourself--if you aren't 100% consistent about using a container, then jai may be for you, because it just works in every single scenario.

I can honestly say that since developing jai, I haven't run an assistant outside of a container. In fact, I now only have the assistants installed inside containers, so if I run `claude`, command not found, it has to be `jai claude`. The only place I have to run outside of jai is for testing jai itself, for which I use a virtual machine and just let the assistant have root, but that's a heavyweight environment I'm forced to use for this particular problem domain.

jai uses persistent file systems for your changes (except for `/tmp`, `/var/tmp` and `/run/user`, which usually aren't persistent anyway). The data is stored under `$HOME/.jai` by default. But you can also expose specific directories to persist state in your home directory like `jai -d ~/.codex`, which would then survive even if you manually deleted your whole `~/.jai` directory.

Yes, unpacking a tar file is much safer than piping arbitrary code to bash! You can look at the PKGFILE in the directory--it is only 30 lines long and mostly variable assignments. The build/check/package functions are 7 lines of code total. Compare that to something like rustup (910 lines of code), claude (158 lines), or opencode (460 lines).

You can do that, but you need root to set it up each time, and it's not super convenient--you need to decide in advance which user account you are going to work under, and you may end up with files you can read from your regular account. Think of jai strict mode as a slightly easier to use and more secure version of what you described. Using id-mapped mounts enables you and the unprivileged user account both to access the same directory with the same credentials, but you didn't need to decide in advance which directories you wanted to expose. Also, things like disabling setuid and using pid namespaces provide an additional measure of isolation beyond what you get from another account.

Yes, people very much are, and that's exactly the problem! People run `claude --dangerously-skip-permissions` and `codex --yolo` all the time. And I think one of the appeals of opencode (besides cross-model, which is huge) is that the permissions are looser by default. These options are presumably intended for VM or container environments, but people are running them outside. And of course it works fine the first 100 times people do it, which drives them to take bigger and bigger risks.

Also, a lot of people use multiple harnesses. I'm often switching between claude, codex, and opencode. It's kind of nice to have the sandbox policy independent of the actual AI assistant you are running.

What distro are you using? The only two dependencies are libacl and libmount. I'm trying to figure out which distros don't include these by default, and if the libraries are really missing, or if it's just the pkgconf ".pc" files. In the former case I should document the dependencies. In the latter case I should maybe switch from PKG_CHECK_MODULES to old-fashioned autoconf.

Human author here. The fact that I don't know web design shouldn't detract from my expertise in operating systems. I wrote the software and the man page, and those are what really matter for security.

The web site is... let's say not in a million years what I would have imagined for a little CLI sandboxing tool. I literally laughed out loud when claude pooped it out, but decided to keep, in part ironically but also since I don't know how to design a landing page myself. I should say that I edited content on the docs part of the web site to remove any inaccuracies, so the content should be valid.

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have a small <3000-line human-implemented program as another layer of defense offers meaningful additional protection.

The problem is that in practice, many people don't take the flamethrower to the shed. I recently had a conversation with someone who was arguing that you don't really need jai because docker works so well. But then it turned out this person regularly runs claude code in yolo mode without a container!

It's like people think that because containers and VMs exist, they are probably going to be using them when a problem happens. But then you are working in your own home directory, you get some compiler error or something that looks like a pain to decipher, and the urge just to fire up claude or codex right then and there to get a quick answer is overwhelming. Empirically, very few people fire up the container at that point, whereas "jai claude" or "jai -D claude" is simple enough to type, and basically works as well as plain claude so you don't have to think about it.

It's a good point. Maybe I should add an option to make certain directories read-only even under the current working directory, so that you can make .git/ read-only without moving it out of the project directory.

You can already make CWD an overlay with "jai -D". The tricky part is how to merge the changes back into your main working directory.

What would it take for people to stop recklessly running unconstrained AI agents on machines they actually care about? A Stanford researcher thinks the answer is a new lightweight Linux container system that you don't have to configure or think about.