[HN Gopher] Show HN: Yolobox - Run AI coding agents with full su...
___________________________________________________________________
Show HN: Yolobox - Run AI coding agents with full sudo without
nuking home dir
Author : Finbarr
Score : 43 points
Date : 2026-01-12 18:34 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| akurilin wrote:
| 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.
| Finbarr wrote:
| 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.
| randall wrote:
| 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?
| Finbarr wrote:
| 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?
| randall wrote:
| Nope, apple container just runs a lot more efficiently on
| apple silicon macs than docker.
| jcjmcclean wrote:
| 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.
| Finbarr wrote:
| Absolutely! Let me know if you have any feedback.
| cyanydeez wrote:
| Have you tried redteaming this and seeing if the LLMs can
| breakout
| LayeredDelay wrote:
| 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.
| Finbarr wrote:
| 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.
| osks wrote:
| 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.
| jacquesnadeau wrote:
| 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.
| carshodev wrote:
| 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?
| Finbarr wrote:
| 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.
| beepbooptheory wrote:
| But then what do you _do_ with that? Is the software
| distributable /buildable outside of the container after all
| that?
| Finbarr wrote:
| 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.
| vunderba wrote:
| 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._
| mtlynch wrote:
| 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.
| Finbarr wrote:
| Good feedback, thank you. We expanded the README:
| https://github.com/finbarr/yolobox/commit/ad776012f82f9d67e1...
| mtlynch wrote:
| Cool, those updates are helpful!
| woodson wrote:
| This is basically a devcontainer, right?
| Finbarr wrote:
| Yes, with some niceties around coding agents preconfigured.
| gingerlime wrote:
| 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)?
| Finbarr wrote:
| 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.
| gingerlime wrote:
| 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.
| globular-toast wrote:
| 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/
| delijati wrote:
| 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.
| m-hodges wrote:
| 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.
| Finbarr wrote:
| 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.
| SilentM68 wrote:
| 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 :(
| canadiantim wrote:
| How would this compare with e.g. the .devcontainer docker files
| that AI coding companies like Claude Code provide already setup?
| Finbarr wrote:
| 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.
| Aperocky wrote:
| 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.
| MadnessASAP wrote:
| 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.
| lvspiff wrote:
| 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.
| AlexCoventry wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-12 23:00 UTC)