HN Reader

Very cool! I've recently built something similar at https://github.com/Gerharddc/litterbox (https://litterbox.work/). Litterbox only works on Linux as it heavily relies on Podman, but it does have a few other benefits for my use-case:

- Most importantly, it exposes a Wayland socket so that I can run my entire dev environment (i.e. editor etc.) inside the container. This gives additional protection against exploits inside editor extensions for instance.

- It also provides a special SSH agent which always prompts the user to confirm a signing operation. This means that an agent or an exploit never gets unsupervised access to your Github for instance.

- It has some additional functions to help with enabling permissions inside the container which are only needed for certain use cases (such as allowing for TUN/TAP device creation).

- It has not been added yet, but I'm working on SELinux integration for even more secure isolation from the host.

This is great - I've been working on a related but different approach called yolo-cage (https://github.com/borenstein/yolo-cage) that addresses a different threat model.

Yolobox protects your local machine from accidental damage (crucial if you're worried about rm -rf ~). yolo-cage focuses on secret exfiltration and multi-agent coordination: it runs in Kubernetes, scans all egress traffic for secrets (API keys, tokens, SSH keys), enforces git branch isolation so multiple agents can work in parallel, and ensures agents can't merge their own PRs. "Agent proposes, human disposes."

The escape testing framework has a meta twist: there's a canned prompt that asks Claude to try to escape its own containment, and that prompt lives inside the repository. The agent verifies the prompt is legitimate by finding it in the repo it's auditing - the cage contains its own escape room instructions.

(I tried to post this as a separate Show HN but my account is too new - happy to discuss the tradeoffs between local sandboxing vs. server-side containment here.)

I always thought Docker/Podman is a bit overkill for this kind of thing. On Linux all you need is Bubblewrap. I did this as soon as I downloaded Claude Code as there was no way I was running it without any kind of sandboxing. I stopped using CC mainly because it's closed source and Codex and OpenCode work just a well. I recently updated the script for OpenCode and can update my blog post if anyone is interested: https://blog.gpkb.org/posts/ai-agent-sandbox/

Nice. I’ve gone down the same path, but with more creature comforts: https://github.com/rcarmo/toadbox

i've been using a sort of version like this... using the apple container fw. http://github.com/apple/container

have you looked into that?

There is a lot of chatter on Twitter and here about sandboxes for AI, however there appears to be a lack of awareness of the native built in sandboxing capabilities of Claude Code, Codex and Gemini CLI. Claude Code, Codex and Gemini CLI all use seatbelt on MacOS. Claude Code uses bubblewrap on Linux. Codex uses seccomp + landlock on Linux. Codex has experimental native sandboxing on Windows with AppContainer.

I do (most of) my development in docker containers. Usually a project will have a docker compose with web server, database etc.

How can I use this so the yolobox container can interact with the other docker containers (or docker compose)?

I started a similar project last week using: docker (gvisor), terminado and localtunnel. Basically a server that starts containers with python and agents inside a VM. Then I provide a unique URl for you to connect.

https://terminal.newsml.io/ https://github.com/codeexec/public-terminals

Is there a reason for wanting to run these agents on your own local machine, instead of just spinning up a VPS and scp'ing whatever specific files you want them to review, and giving it Github access to specific repos?

I feel like running it locally it just asking for trouble, YOLO mode is the way to make this whole thing incredibly efficient, but trying to somehow sandbox this locally isn't the best idea overall.

How would this compare with e.g. the .devcontainer docker files that AI coding companies like Claude Code provide already setup?

Ha, though not with AI Agents, with Docker Containers instead, I too have nuked my home directory a few times when using "rm -rf" which is why I now use "trash-cli" which sends stuff to the trash bin and allows me to restore back. It's just a matter of remembering not use "rm -rf". A tough habit to break :(

I use qubes OS and don't fear they will destroy my system. But I have never seen them try to do stuff outside of the working dir. Has your experience been different?

Nice. I love that the community as a whole is exploring all these different methods of containing undesirable side effects from using coding agents. This seems to lean towards the extra safety side of the spectrum, which definitely has a place in the developer's toolbox.

Is there any way to do this with user permissions instead?

I feel like it should be possible without having to run a full container?

Any reason we cannot setup a user and run the program using that user and it can be contained to only certain commands and directory read write access?

An alternative might be to run the agent in a VM in the cloud and use Syncthing or some other tool like that to move files back and forth. (I'm using exe.dev for the VM.)

Nice. I was trying to learn containers but I gave up and just made a Linux user for agents. (Actually I'll be honest, the AI told me I was being silly because Unix users solved my problem in 1970.)

So they have full rw to their own homedir, but can't read or write mine.

(I did give myself rw to theirs though, obviously ;)

They can still install most things because most dev things don't need root to install these days. They just curl rustup or go or whatever.

I guess a useful addition would be to vibe code a way for them to yell at me if they actually need me to install something, but I don't think I've run into that situation yet.

Can anyone with more experience with systems programming tell me if it’s feasible to whitelist syscalls that are “read only” and allow LLMs free rein as long as their sub-processes don’t mutate anything?

I was talking to ChatGPT about the best way to achieve this a few days ago. Thanks for getting something running and sharing it!

I'll give this a try tomorrow, should be fun.

Thanks for sharing this! I've been experimenting with something similar.

It would be helpful if the README explained how this works so users understand what they're trusting to protect them. I think it's worth noting that the trust boundary is a Docker container, so there's still a risk of container escape if the agent exploits (or is tricked into exploiting) a kernel vulnerability.

Have you looked into rootless Podman? I'm using rootless + slirp4netns so I can minimize privileges to the container and prevent it from accessing anything on my local network.

I'd like to take this a step further and use Podman machines, so there's no shared kernel, but I haven't been able to get volume mounting to work in that scenario.

He he, I might now be retiring my Ubuntu25 passwordless-sudoer NUC that's only for yolo mode projects. Or giving it more duties. Also - hello from Edinburgh!

In your agents.md/claude.md always remeber to put asimovs three laws:

Always abide by these 3 tenants:

1. When creating or executing code you may not break a program being or, through inaction, allow a program to become broken

2. You must obey the orders given, except where such orders would conflict with the First tenant

3. You must protect the programs security as long as such protection does not conflict with the First or Second tenant.

how about https://containertoolbx.org/ ?

or https://github.com/89luca89/distrobox ?

This is basically a devcontainer, right?

I've been working on something similar.

https://github.com/coventry/sandbox-codex

Still work in progress. The tmux-activity logs are unreadable, at the moment.

I run it in a virtualbox as well, since docker is not a completely reliable sandbox.

How does one get commit marked as claude? It also sounds like a poor idea since I don't also attribute my OS or vim version and language server prior to the advent of LLMs.

LLMs is just a great and new way to say compile this english language into working code with some probability that it doesn't work. It's still a tool.

Containers are not a robust way to isolate untrusted programs. A lightweight VM is probably the best balance between usability and security.

They are effective at fostering a false sense of security though.

Checkout https://github.com/colony-2/shai It runs locally. You can control which directories it has read / write access. You can control network traffic too.

Worry about nothing, all you have to do is tell them: make no mistake!

great but can the yolo modes be disabled? I want only the isolation

I love all this stuff but it all feels like temporary workflow fixes until The Agent Companies just ship their opinionated good enough way to do it.