Earlier quoted context omitted.
All 1 of them?
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.
Your thinking is wrong.
Running Claude Code dangerously (safely)
231–240 of 265 posts
Re: Running Claude Code dangerously (safely)
#232Earlier quoted context omitted.
What is the advantage of using VMware Workstation Pro for this as opposed to using WSL2?
I think it has default access to your c drive via a mount, for one. You could add layers/sandboxes, but it’s not isolated.
I wouldn't put it past Opus 4.5 in yolo mode to vm escape if it felt like it haha
Re: Running Claude Code dangerously (safely)
#233Earlier quoted context omitted.
Windows has the WSL for native Linux vms, these days (and also the past ~decade)
I can rm -rf Windows files from WSL2. And so can LLMs. Meanwhile a VM isolates by default.
You can turn all the interop and mounting of the windows FS with ease. I run claude in yolo mode using this exact setup. Just role out a new WSL env for each claude I want yoloing and away it goes. I suppose we could try to theorize how this is still dangerous buts its getting into extremely silly territory.
Re: Running Claude Code dangerously (safely)
#234It 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.
Re: Running Claude Code dangerously (safely)
#235Hey - Srini from Docker here. We’ve seen a lot of developers turn to Docker for this use case and heard some mentions of the Docker-in-Docker block. We put out Docker Sandboxes in experimental preview as a potential answer. Still early but we're working on the next iteration based on MicroVMs and avoids Docker-in-Docker.
How does docker sandbox solve the docker-in-docker issue? Can Claude running in docker sandbox spin up other docker containers, without having privileged access?
Re: Running Claude Code dangerously (safely)
#236Earlier quoted context omitted.
I can rm -rf Windows files from WSL2. And so can LLMs. Meanwhile a VM isolates by default.
You can turn all the interop and mounting of the windows FS with ease. I run claude in yolo mode using this exact setup. Just role out a new WSL env for each claude I want yoloing and away it goes. I suppose we could try to theorize how this is still dangerous buts its getting into extremely silly territory.
That's great to know! And important to clarify because by default WSL has access to
all disks.
Re: Running Claude Code dangerously (safely)
#237Hey - Srini from Docker here. We’ve seen a lot of developers turn to Docker for this use case and heard some mentions of the Docker-in-Docker block. We put out Docker Sandboxes in experimental preview as a potential answer. Still early but we're working on the next iteration based on MicroVMs and avoids Docker-in-Docker.
How does docker sandbox solve the docker-in-docker issue? Can Claude running in docker sandbox spin up other docker containers, without having privileged access?
micro-vms, not DinD
Re: Running Claude Code dangerously (safely)
#238Devcontainer is not docker and do the trick!
Re: Running Claude Code dangerously (safely)
#239> What you’re NOT protecting against: > a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation) No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command. If you're only worried about mistakes, Claude could decide to fix/improve something by adding a…
Maybe before 'vagrant up' you run 'sudo chattr +i Vagrantfile' to make it immutable. Seems to disallow removal of the attribute inside the VM, but allow it outside.
Re: Running Claude Code dangerously (safely)
#240I just throw it into an unpriviledged LXC and call it a day. Threat model for me is more "whoops it deleted my home directory" rather than some elaborate malicious exploit.
I am considering this in the context of proxmox - what is your workflow for LXC, may I ask?