In this way I'm not afraid of letting the agents totally lose on my computer.
Instead of generating patches, this exposes the agent's checkout as a git remote though.
Most similar tools (and I believe your tooling as well?) bind-mount the repository checkout from the host into the container. This was always a source of user and permission errors for me, since you have to align the user ids inside and outside the container. Also, some build tools don't like it when the repo is on a different filesystem (bind mount vs container root) than the rest of the system. So I made rumpelpod just bake the repo checkout into the base image that the container is launched from, and since then I haven't had any issues like this.
For giving the agent access to a docker daemon I found sysbox to work very well. Usually the advice for nested containers is to pass in the host's docker socket into the container. But that would break the outer container isolation completely, since access to the docker daemon is equivalent to root access on the host. With sysbox it's trivial to run a nested docker instance inside the outer container. I haven't tried it with podman yet though. In theory sysbox is just another OCI runtime, but there's probably some tinkering required to get it to work.
I explain a bit more over here: https://news.ycombinator.com/item?id=48893874
docker run --rm -it -v $(pwd):/src -w /src alpine sh
Note entirely perfect, but will be enough against anyone not actively exploiting kernel privilege escalation bugs.
Sorry if it's a dumb question - I'm just getting into sandboxing for the first time myself and ran into this same thought before.
In the README it mentions that it puts the dev environment in a filesystem jail, but how are you able to use your hosts bins without leaking access to the rest of the system? Or is that just an assumed liability?
It copies the current Git repo into the sandboxes dir, mounts that copy at /workspace in the container. The original repo is never mounted writable, so I don't care if the agent goes to town/wild in there (peace of mind).
It also builds cached Debian/mise/Elixir/Phoenix images, can start a private Postgres container, publishes selected localhost ports, reuses dependency/build caches, and prints commands on exit for reviewing diffs, exporting patches, applying them back to the real repo, or reopening the same sandbox later. Pi, and OpenCode are configured with proper LLM access keys (derived from my own).
So spinning a new sandbox is a matter of cding into a project directory and run something like: `ai-sandbox --port 4000 --postgres somedbname` or `ai-sandbox --port 4001` if I don't need DB support. Then when running the server in the container I can access it from the host machine to review in my browser.
It brings some extra sandboxing features compared to just a docker container.
For instance it also maps the secrets that the agent harness has access to. And has an allow list for outgoing http connections. And there's a way for agents to request extra access. And once approved by the user from an external cli the policy is updated and hot reloaded.
It's pretty recent. So time will tell how robust it is / will become. What its longevity will be. After all; in a time of LLMs one off experiments are cheap. Longtime nurturing not so much.
But it turns out even in the container, there are footguns that have occasionally made the news by being fired: few projects don't have any external resources and when credentials with any form of write access happen to make it into the container (even if it's just a session cookie) agents might jump at the opportunity.
Or, the internal sandboxing.
Sure, for IT crowd containers are a no-brainer and due to existence of validation software like compilers, linters, interpreters, analyzers etc. using LLMs is efficient, safe and rational.
But the problem is that they are also advertised to the remaining 99% of population too. You can't sandbox a bank, a broker or an exchange. You can't sandbox your email, calendar and other such tools (you can, but not in any way that will be used by non-IT people in any real work conditions). You can't sandbox messengers, social networks etc. And the list goes on. These people will either use so called "agents" in production under root, so to speak, or they won't use "agents" at all. They have no safety option, and they aren't properly informed about that by the peddlers of the LLM rapture.