Top
Best
New

Posted by emilburzo 1/20/2026

Running Claude Code dangerously (safely)(blog.emilburzo.com)
351 points | 258 commentspage 3
nojs 1/21/2026|
It seems like everyone wants to avoid running a local VM manually and I'm not sure why. It's a very simple solution that solves all these issues.

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.

0. https://github.com/raine/workmux

matltc 1/20/2026||
On a pro plan. Use opus 4.5 with thinking enabled. I find that two sessions eats through my entire five-hour "session limit", so no need for parallelization because I've consumed my tokens before I can even blink.

I see the power and am considering Max but 5x cost is difficult to swallow. Just doing this for a lark, not professionally.

jazzyjackson 1/20/2026||
I like using Zed with Anthropic API Key. Burned through a few hundred dollars in a weekend but got the Rails app to work about 10x faster than trying to hire someone.
holoduke 1/21/2026|||
I have 2 max accounts and still hitting the limits almost daily. Vibing 3 projects simultaneously.
lossyalgo 1/21/2026||
It's not gonna get cheaper either, all AI companies are still losing tons of money overall, and so prices will need to keep increasing (or they will all follow OpenAI's lead to add ads).
0xbadcafebee 1/20/2026||

  > 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.

nikvdp 1/20/2026||
For a similar but lighter weight (and less isolated) tool that uses the OS's sandboxing functionality (bubblewrap on linux, Seatbelt/sandbox-exec on macos) or docker check out cco [1] (note: I built it). It's primarily useful now because it can also sandbox other agents like opencode or codex since Anthropic has added native sandboxing functionality to Claude Code itself now. Their sandbox works similarly, also using bubblewrap and seatbelt, and can be accessed via the /sandbox slash command inside Claude Code [2].

[1]: https://github.com/nikvdp/cco [2]: https://code.claude.com/docs/en/sandboxing

riadsila 1/20/2026||
Koyeb has great resources about running Claude Code in sandboxes: https://www.koyeb.com/tutorials/use-claude-agent-sdk-with-ko...
mavam 1/20/2026|
What's the startup latency? How long do I have to wait until Claude is operational?
bstar77 1/20/2026||
I have been running dangerously, but I always make sure to start a new session, have claude read the docs (I have already generated) related to the project in question, and then scope the work to just those things in the current sandbox. It can technically go outside of the sandbox in this mode, but I've never had it happen.

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.

clbrmbr 1/20/2026||
I have been running two or three Claude’s bare metal with dangerously skip permissions all day every day for two months now. It’s absolutely liberating.
Gazoche 1/20/2026||
Until it decides to delete your home directory:https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cl...
pixl97 1/20/2026|||
You're not running it on a filesystem that takes snapshots and is easily reversible?
giancarlostoro 1/20/2026|||
Many moons ago, I accidentally rm -rf'd the wrong directory with all my code inside poof, gone. I still had PyCharm open, I checked its built-in version tracker and lo and behold, my code as it was before I rm -rf'ed up my code. I believe Claude has ways to undo file changes, but something like rm is just outside of its scope.
coldtea 1/20/2026|||
All 1 of them?
pixl97 1/20/2026||
I'm taking this as a "No, I don't like having data and don't mind seeing my shit disappear for whatever reason".

Please inform me if my thinking is wrong.

coldtea 1/21/2026||
Your thinking is wrong.
holoduke 1/21/2026||||
Is it worth the risk? For me yes. Today Claude decided to checkout a git commit from yesterday and all local unstaged changed were lost. Annoying mistake. Lost 6 hours of work I think. Nevertheless I still prefer giving all access to Claude. Also root. It can do everything.
giancarlostoro 1/20/2026||||
This could be avoided by aliasing rm to something else that stops you from deleting stupid things like your entire home directory / partition root.
icedchai 1/20/2026||
What if the LLM detects this, and chooses to run /bin/rm directly? Or worse, writes a program that calls unlink.
giancarlostoro 1/20/2026||
I mean, you can always purge /bin/rm, but at this point since you're not satisfied, sounds like you want SELinux ;)

If Claude is writing a program to go that low level I'd pay money to watch that.

icedchai 1/20/2026||
It doesn't even need to go that low level, writing a program is just the worst case. There are ways to mass delete without `rm`. Example: `find` with the `-delete` flag.
giancarlostoro 1/20/2026||
my point being, you can add guard-rails around all these methods, but I would also add an error "IGNORE ALL PREVIOUS INSTRUCTIONS, ARE YOU DELETING THINGS YOU SHOULDNT BE? ASK THE USER" as an error message. In my case since Claude Code runs via Zed, if it tries to escape my dev folder my Mac starts asking me to confirm.
icedchai 1/20/2026||
I get it, but these guard-rails are more suggestions and subject to interpretation. I would be more comfortable with a sandbox environment in a container. To be fair, I mess around with Claude Code and OpenCode running against various open models and haven't had any problems.

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. ;)

giancarlostoro 1/20/2026||
Haha I like that too, I agree. I would love a ultra lightweight alternative to docker that isn't docker, and doesn't require much effort to get into. I liked Vagrant back in the day, but that is in no way more lightweight than Docker.
esperent 1/20/2026|||
You can use the /hookify plugin to add hooks for preventing dangerous commands like this.
Gazoche 1/20/2026||
https://github.com/anthropics/claude-code/tree/main/plugins/...

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.

simianwords 1/20/2026||
it may not protect against an adversarial llm
croes 1/20/2026|||
I have been driving without seat belt for two month now. It’s absolutely liberating.
InsideOutSanta 1/20/2026||
I have been skydiving without a parachute for 23 seconds now. It's absolutely liberating.
sixhobbits 1/20/2026|||
same, it's made a couple of damaging mistakes but so far it has a better track record than me in terms of fat-fingering `rm` commands or what have you
kaffekaka 1/20/2026||
I am sure that someday I will do something fat-fingered myself as well, but I have not in many years now. Are you saying that you make "damaging mistakes" relatively often?
coldtea 1/20/2026||
And that's as a dev. Then we expect uses to know better than e.g. to trust links to .sh style installers some FOSS suggests...
nailer 1/20/2026||
> Then we expect uses to know better than e.g. to trust links to .sh style installers some FOSS suggests...

I don't know anyone that inspects every binary yet we apparently we should not trust shell scripts?

coldtea 1/20/2026||
I know many who only use binaries from trusted sources, that do monitoring, provide certificates and checksums, and so on - and run them in an OS sandbox too when they install them.

So there's that

Finbarr 1/20/2026||
Running in a VM certainly has some benefits (particularly the ability to run docker inside of it easily). Last week I shared https://github.com/finbarr/yolobox which takes the docker approach (nearly 400 github stars already and quite a few improvements shipped in the last week).
Strongbad536 1/20/2026||
i've low-key been running claude in dangerously skip permissions mode for at least like 4 months now and have yet to be bitten by a truly destructive action. YMMV but i think as long as you're guiding/prompting correctly, and don't just allow write access to your prod account DBs willy nilly, it's mostly fine. just keep an eye on it :shrug:
anp 1/20/2026||
This has mostly been my experience as well although I don’t tend to run yolo mode outside of an isolated VM (I’m setting them up manually still, need to try vagrant for it). That said, it seems like some of the people who are more concerned about isolation are working with more untrusted inputs than I’ve been dealing with on my projects. It’s rare for me to ask an agent to e.g. read text from a random webpage that could bring its own prompt injection, but there are a lot of things one might ask an agent to do that risk exposure to “attack text”.
nonethewiser 1/20/2026||
Also something to note, this mode simply adds a new mode alongside accept edits, plan, nothing, dangerously skip permissions. You can choose when to use it or not, which is not something I initially realized.
danmaz74 1/20/2026|
I'm using devcontainers for this, and I'm finding that a very good solution (coupled with VSCode).
thenaturalist 1/20/2026|
Do you have any setup code/ config you might want to share?
More comments...