Posted by emilburzo 1/20/2026
If you're on a Mac working on a linux docker containers, your Docker engine is already running a VM (and a linux VM doesn't need one). So you're still only "one VM away" from the real environment. Most IDEs support directly working in the VM via SSH if you need to inspect the code.
You then run --dangerously-skip-permissions and do all changes via PRs. I have been running this combined with workmux [0] for a couple of months and highly recommend it. You can one-shot several whole PRs concurrently with this setup.
The reason it beats a cloud VM is because when you're running multiple concurrent copies of all containers in a project, it quickly eats up memory. Running a cloud VM 24/7 with high enough memory is expensive.
I see the power and am considering Max but 5x cost is difficult to swallow. Just doing this for a lark, not professionally.
> So now you need Docker-in-Docker, which means --privileged mode, which defeats the entire purpose of sandboxing.
> That means trading “Claude might mess up my filesystem” for “Claude has root-level access to my container runtime.”
A Vagrant VM is exactly the same thing, just without Docker. The benefit of Docker is you've got an entire ecosystem of tooling and customized containers to benefit from, easier to maintain than a Vagrantfile, and no waiting for "initialization" on first booting a Vagrant box.On both Linux and MacOS, use this:
# Build 'claude' VM and Docker context
$ colima start --profile claude --vm-type=qemu
$ docker context create claude --docker "host=unix://$HOME/.colima/claude/docker.sock"
$ docker context use claude
# Start DinD, pass through ports 8080 and 8443, and mount one host directory (for a Git repo)
$ docker run -d --name dind-lab --privileged -e DOCKER_TLS_CERTDIR= -v dind-lab-data:/var/lib/docker \
-p 8080:8080 -p 8443:8443 -v /home/MYUSER/GITDIR:/mnt/host/home/MYUSER/GITDIR \
docker:27-dind
$ docker run --rm -it -e DOCKER_HOST=tcp://127.0.0.1:2375 \
-p 8080:8080 -p 8443:8443 -v /mnt/host/home/MYUSER/GITDIR:/home/MYUSER/GITDIR \
ubuntu:24.04 bash
# Or if you don't want to pass-through ports w/ DinD twice, use its network namespace directly
# ( docker run --rm -it -e DOCKER_HOST=tcp://127.0.0.1:2375 --network container:dind-lab .... )
Your normal default Docker context remains safe for normal use, and the "dangerous" context of claude euns in a different VM. If Claude destroys its container's VM, just delete it (colima stop claude; colima delete claude) and remake it.You could do rootless Docker/Podman, but there's a lot of broken stuff to deal with that will just distract the AI.
[1]: https://github.com/nikvdp/cco [2]: https://code.claude.com/docs/en/sandboxing
IMO, if you are not running in the dangerous mode then you are really missing out on one of the best aspects of claude code- its ability to iterate. If you have to confirm each iteration then it's just not practical.
Please inform me if my thinking is wrong.
If Claude is writing a program to go that low level I'd pay money to watch that.
Also, is overwriting the same a deleting? Maybe it will just clobber your files with echo >file and mv them out of the way.
Maybe it realizes you have Time Machine backups enabled, so deleting your entire directory is permitted since it's not actually deleted. ;)
So it's basically adding "don't delete my files pretty please" to the prompt?
EDIT: I misread, the natural language description of the rule is just a shortcut to generate the actual rule which is based on regexp patterns.
Still, it only protects you against very specific commands. Won't help you if the LLM decides to fill your disk with `cat /dev/urandom > foo` for example.
I don't know anyone that inspects every binary yet we apparently we should not trust shell scripts?
So there's that