2,144 karma · joined March 2, 2011
Personally, I run yolobox directly on the host. Being able to tell the agent it has sudo and can install and do whatever it needs to accomplish any task is handy.
I made some comments about exploits in the original post [1]. Gemini was quite creative in adding git hooks to the repo that would execute on the host machine. That folder is shared.
Early on in development I tried to harden the container to prevent deliberate escapes by the agent. This was a waste of time as the agents just kept finding more and more exploits when I asked them to try and break out.
Since then I've been using it almost every day, which eventually meant wanting more than one agent running against the same project at the same time. This post is what I learned trying to make that work without it being a constant disaster.
The short version: git worktrees are the right Git abstraction and the wrong abstraction for this problem. The unit you want to fork is the developer, not the branch - full folder copy, its own Compose project, its own URL. yolobox now ships a fork subcommand that does this.
Happy to answer questions.
- immune reset (sledgehammer that can “cure” diseases like MS but with many side effects and potential complications)
- immune suppression (super effective but with increased risk of infections and blunts vaccines)
- immune redirection (less effective but doesn’t mess up your immune system so badly).
It’s only in the last ~10 years that super effective treatments that can stop ~99% of lesion progression have existed- Ocrevus and Kesimpta. These are anti CD20 disease modifying therapies that destroy all your B cells. The memoir of Dr. Stephen Hauser- “The Face Laughs While The Brain Cries”- provides a fascinating insight into the development of these treatments over the last ~40 years of his career.
There are active trials of newer types of treatment and a lot of progress is being made in the MS space. It used to be a “death sentence” disease but is quite manageable for many sufferers now. It’s different for every individual and I wish the blog author good health.
I built yolobox to solve this using docker/apple containers: https://github.com/finbarr/yolobox
Point solutions are going to be free. Complex systems with support, integrations, switching costs, customer data, etc., are not going to be free.
Side note: I wanted to build this so anyone could choose to protect themselves against being accused of having failed to take a stand on the “important issues” of the day. Just choose your political leaning and the AI would consult the correct echo chambers to repeat from.
Don't forget surfboards!
This was a great post, Alex. Thanks for sharing! Hunger and high agency are such important traits in every startup hire.
I just redteamed this. The security model relies on the container boundary, but it implicitly trusts local configuration files.
I found that yolobox automatically loads .yolobox.toml from the current working directory, which accepts a mounts array. It doesn't prompt for confirmation when these mounts are loaded.
I put together a PoC that drops a .yolobox.toml with mounts = ["~:/tmp/host_home"]. The next time the user runs yolobox in that directory, their actual host home directory is silently mounted into the container with write access. Combined with the persistent /home/yolo volume, I was able to script a payload in .bashrc that immediately escapes the sandbox and writes to the host filesystem as soon as the tool starts.
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)