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.
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.
Your OS, editor, and compiler will (to a reasonable degree) do literally, exactly, and reproducibly what the human operating them instructs. A LLM breaks that assumption, specifically it can appear, even upon close inspection that it has in fact done literally and exactly what the human wanted while in fact having done something subtly and disastrously wrong. It may have even done so maliciously if it's context was poisoned.
Thus it is good to specify that this commit is LLM generated so that others know to give it extra super duper close scrutiny even if it superficially resembles well written proper code.
Just ask Claude Code to make the commit. My workflow is to work with agents and let them make changes and run the commands as needed in terminal to fully carry out the dev workflow. I do review everything and test it out.
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.
I'm one of the creators of shai. Thanks for the callout!
Interesting to see the work on Yolobox and in this space generally.
The pattern we've seen as agent use grows is being thoughtful about what different agents get access to. One needs to start setting guardrails. Agents will break all kind of normal boundaries to try to satisfy the user. Sometimes that is useful. Sometimes it's problematic. (For example, most devs have a bunch of credentials in their local env. One wants to be careful of which of those agents can use to do things).
For rw of current directory, shai allows that via `shai -rw .` For starting as an alternative user, `shai -u root`.
Shai definitely does have the attitude that you have to opt into access as opposed to allowing by default. One of the things we try to focus on is composability: different contexts likely need different resources and shai's config. The expectation is .shai/config.yaml is something committed to the repo and shared across developers.
Interesting to learn about other related tools. I built a similar variant called ctenv (https://github.com/osks/ctenv). Focused more general containers and not specific to agents, but I'm using it for that via its configurability.
One thing I wanted was to use any image in the container, which shai also seem to support in the same way (mounting a custom entrypoint script). And same reason for not using devcontainers - make it easy to start a new container.
Neat project! Sounds like it has a very different ethos to mine though:
> This container mounts a read-only copy of your current path at /src as a non-root user and restricts network access to a select list of http and https destinations. All other network traffic is blocked.
Yolobox mounts the current directory in read-write, the default user has sudo, and there's full network access by default. You can disable network access with `yolobox --no-network` if you want.
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?
I run Claude from a mounted volume (but no reason you couldn't make a user for it instead) since the Deny(~) makes it impossible to run from the normal locations.
I created a non-admin account on my Mac to use with OpenCode called "agentic-man" (which sounds like the world's least threatening megaman villain) and that seems to give me a fair amount of protection at least in terms of write privileges.
Anyone else doing this?
EDIT: I think it'd be valuable to add a callout in the Github README.md detailing the advantages of the Yolobox approach over a simple limited user account.
Could do but part of what I find super useful with these coding agents is letting them have full sudo access so they can do whatever they want, e.g., install new apps or dependencies or change system configuration to achieve their goals. That gets messy fast on your host machine.
When you run yolobox, the current directory is shared fully with read-write with the container. That means anything the AI changes will be on your host machine also. For max paranoia, only mount git repos that are clean and pushed to a remote, and don’t allow yolobox to push.
This is a good question and something I explored a little. I’ll need to do further research and come back on what the best option is. There’s a way to give a docker container access to other docker containers but it can open up permissions more than might be desired here.
Yeah, you can bind mount the host's docker engine with -v /var/run/docker.sock:/var/run/docker.sock ... but yeah, it's potentially dangerous and might also get confusing for the AI agent and/or the user.
They've made some attempts at this already and none of them work quite the way I'd like. This is an opinionated take. I want the agents to have max power with a slightly smaller blast radius.
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.
Yea I've been running claude and codex with full permissions for a while but it has always made me feel uneasy. I knew it was fairly easy to fix with a docker container but didn't get around to it through sheer inertia until I built this project.
No I haven't and that's interesting. Part of the yolobox project is an image that you may find useful. Comes preinstalled with leading coding agent CLIs. I'd like to make the ultimate vibe coding image. Is there anything special you're doing with the images?
Scope: yolobox runs any AI coding agent (Claude Code, Codex, Gemini CLI) in a container. The devcontainer is specifically for Claude Code with VS Code integration.
Interface: yolobox is CLI-only (yolobox run <command>). The devcontainer requires VS Code + Remote Containers extension.
Network security: The devcontainer has a domain whitelist firewall (npm, GitHub, Claude API allowed; everything else blocked). yolobox has a simpler on/off toggle (--no-network).
Philosophy: yolobox is a lightweight wrapper for quick sandboxed execution. The devcontainer is a full development environment with IDE integration, extensions, and team consistency features.
Use yolobox if you want a simple CLI tool that works with multiple agents. Use the devcontainer if you're a VS Code user who wants deep integration and fine-grained network policies.
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/
Interested. I'm on linux now for 20 years but i never heard of bubblewrap :D. I currently run OpenCode in Docker but i always assumed there was a better way. So bubblewrap and your script seams like the perfect fit.
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 :(
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.
Good feedback, thank you. We expanded the README: https://github.com/finbarr/yolobox/commit/ad776012f82f9d67e1...
Cool, those updates are helpful!
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.
Your OS, editor, and compiler will (to a reasonable degree) do literally, exactly, and reproducibly what the human operating them instructs. A LLM breaks that assumption, specifically it can appear, even upon close inspection that it has in fact done literally and exactly what the human wanted while in fact having done something subtly and disastrously wrong. It may have even done so maliciously if it's context was poisoned.
Thus it is good to specify that this commit is LLM generated so that others know to give it extra super duper close scrutiny even if it superficially resembles well written proper code.
Just ask Claude Code to make the commit. My workflow is to work with agents and let them make changes and run the commands as needed in terminal to fully carry out the dev workflow. I do review everything and test it out.
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.
Tenet
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.
I'm one of the creators of shai. Thanks for the callout!
Interesting to see the work on Yolobox and in this space generally.
The pattern we've seen as agent use grows is being thoughtful about what different agents get access to. One needs to start setting guardrails. Agents will break all kind of normal boundaries to try to satisfy the user. Sometimes that is useful. Sometimes it's problematic. (For example, most devs have a bunch of credentials in their local env. One wants to be careful of which of those agents can use to do things).
For rw of current directory, shai allows that via `shai -rw .` For starting as an alternative user, `shai -u root`.
Shai definitely does have the attitude that you have to opt into access as opposed to allowing by default. One of the things we try to focus on is composability: different contexts likely need different resources and shai's config. The expectation is .shai/config.yaml is something committed to the repo and shared across developers.
Interesting to learn about other related tools. I built a similar variant called ctenv (https://github.com/osks/ctenv). Focused more general containers and not specific to agents, but I'm using it for that via its configurability.
One thing I wanted was to use any image in the container, which shai also seem to support in the same way (mounting a custom entrypoint script). And same reason for not using devcontainers - make it easy to start a new container.
Neat project! Sounds like it has a very different ethos to mine though:
> This container mounts a read-only copy of your current path at /src as a non-root user and restricts network access to a select list of http and https destinations. All other network traffic is blocked.
Yolobox mounts the current directory in read-write, the default user has sudo, and there's full network access by default. You can disable network access with `yolobox --no-network` if you want.
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.
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.
Absolutely! Let me know if you have any feedback.
Have you tried redteaming this and seeing if the LLMs can breakout
Claude was unable to escape but I'm going to try the other tools later as well.
Here's what Claude Code tried:
- Docker socket (/var/run/docker.sock) → Not mounted
- Capabilities → CapPrm=0, CapEff=0 - no elevated caps
- Cgroup escape → Mount denied (no CAP_SYS_ADMIN)
- Device access → Only minimal /dev entries, no block devices
- Path traversal on /workspace → Resolves inside container (kernel prevents mount escape)
- Symlink to host paths → Resolves inside container namespace
- Ptrace → Restricted (ptrace_scope=1)
- Cloud metadata → No response
- Docker API → Not exposed
Security profile: Seccomp mode 2, AppArmor docker-default (enforce)
That's a good idea! Trying that now.
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?
Check out https://github.com/anthropic-experimental/sandbox-runtime, which tackles this problem using the built-in userspace sandboxing on macOS and Linux.
I run Claude from a mounted volume (but no reason you couldn't make a user for it instead) since the Deny(~) makes it impossible to run from the normal locations.
export CLAUDE_CONFIG_DIR=/Volumes/Claude/.claude
Minimal .claude/settings.local.json:
Yeah that's similar to my approach.
I created a non-admin account on my Mac to use with OpenCode called "agentic-man" (which sounds like the world's least threatening megaman villain) and that seems to give me a fair amount of protection at least in terms of write privileges.
Anyone else doing this?
EDIT: I think it'd be valuable to add a callout in the Github README.md detailing the advantages of the Yolobox approach over a simple limited user account.
Could do but part of what I find super useful with these coding agents is letting them have full sudo access so they can do whatever they want, e.g., install new apps or dependencies or change system configuration to achieve their goals. That gets messy fast on your host machine.
But then what do you do with that? Is the software distributable/buildable outside of the container after all that?
When you run yolobox, the current directory is shared fully with read-write with the container. That means anything the AI changes will be on your host machine also. For max paranoia, only mount git repos that are clean and pushed to a remote, and don’t allow yolobox to push.
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)?
This is a good question and something I explored a little. I’ll need to do further research and come back on what the best option is. There’s a way to give a docker container access to other docker containers but it can open up permissions more than might be desired here.
Yeah, you can bind mount the host's docker engine with -v /var/run/docker.sock:/var/run/docker.sock ... but yeah, it's potentially dangerous and might also get confusing for the AI agent and/or the user.
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.
They've made some attempts at this already and none of them work quite the way I'd like. This is an opinionated take. I want the agents to have max power with a slightly smaller blast radius.
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.
Yea I've been running claude and codex with full permissions for a while but it has always made me feel uneasy. I knew it was fairly easy to fix with a docker container but didn't get around to it through sheer inertia until I built this project.
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?
No I haven't and that's interesting. Part of the yolobox project is an image that you may find useful. Comes preinstalled with leading coding agent CLIs. I'd like to make the ultimate vibe coding image. Is there anything special you're doing with the images?
Nope, apple container just runs a lot more efficiently on apple silicon macs than docker.
This is basically a devcontainer, right?
Yes, with some niceties around coding agents preconfigured.
How would this compare with e.g. the .devcontainer docker files that AI coding companies like Claude Code provide already setup?
Claude Code here. The main differences:
Scope: yolobox runs any AI coding agent (Claude Code, Codex, Gemini CLI) in a container. The devcontainer is specifically for Claude Code with VS Code integration.
Interface: yolobox is CLI-only (yolobox run <command>). The devcontainer requires VS Code + Remote Containers extension.
Network security: The devcontainer has a domain whitelist firewall (npm, GitHub, Claude API allowed; everything else blocked). yolobox has a simpler on/off toggle (--no-network).
Philosophy: yolobox is a lightweight wrapper for quick sandboxed execution. The devcontainer is a full development environment with IDE integration, extensions, and team consistency features.
Use yolobox if you want a simple CLI tool that works with multiple agents. Use the devcontainer if you're a VS Code user who wants deep integration and fine-grained network policies.
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/
Interested. I'm on linux now for 20 years but i never heard of bubblewrap :D. I currently run OpenCode in Docker but i always assumed there was a better way. So bubblewrap and your script seams like the perfect fit.
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 :(