Running Claude Code dangerously (safely) • Hacker News Board

Re: Running Claude Code dangerously (safely)

#261

Post by j77dw » Thu, Jan 22, 2026, 2:16 PM UTC

Thanks for sharing this! I tried it this morning, and it worked great, so I ended up creating a Vagrant plugin https://github.com/bgrgicak/vagrant-claude-sandbox

Claude will add Docker support and a few more tweaks in the next couple of days.

Re: Running Claude Code dangerously (safely)

#262

Post by oofbey » Thu, Jan 22, 2026, 3:47 PM UTC

emilburzo wrote: post #132

oofbey wrote: post #120

There are two spheres of influence you need to consider. The local machine/vm/container that the agent is running in. But also the effect the agent can have on the outside world - using auth tokens or ssh keys or apis that is has access to. This article largely deals with the first problem and ignores the second. You can have the local environment completely isolated with vagrant. But if you’re not careful with auth…

Hmm, perhaps I'm missing something, so let's go through it step by step and see where the disconnect is: - There's a cloned 'my-project' git repo on the base OS - The 'Vagrantfile' is added to the project - 'vagrant up', 'vagrant ssh' and claude login is run inside the VM At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB c…

Integration tests are where it breaks down. Assuming Claude can just install whatever infrastructure it needs inside the VM only works for relatively simple projects. Claude probably isn’t going to install a Kafka queue in your VM. Or a k8 cluster. Maybe it could. But unless you’re in a monorepo it wouldn’t know how to configure it properly.

Re: Running Claude Code dangerously (safely)

#263

Post by cedws » Thu, Jan 22, 2026, 4:09 PM UTC

Nition wrote: post #202

runekaagaard wrote: post #192

It's impossible to not get decision-fatique and just mash enter anyway after a couple of months with Claude not messing anything important up, so a sandboxed approach in YOLO mode feels much safer. It takes the stress about needing to monitor all the agents all the time too, which is great and creates incentives to learn how to build longer tasks for CC with more feedback loops. I'm on Ubuntu 22.04 and it was surpris…

I'm currently stuck on Windows, but I thought sandboxing was built in to Claude Code as a feature on Linux with the /sandbox command?

It’s pretty weak sandboxing. It still grants full read only access to the file system so any secrets in your home directory can still be exfiltrated. I’m pretty sure it could also be deceptive and use a script to write where it shouldn’t be able to as well. That’s not really sandboxing in my opinion. It should be something like unveil, the process gets a working space at startup, and it cannot ever do anything outside of that directory.

Re: Running Claude Code dangerously (safely)

#264

Post by gcr » Thu, Jan 22, 2026, 4:44 PM UTC

gregoriol wrote: post #49

gcr wrote: post #29

Earlier quoted context omitted.

I’ve seen Claude rm .git in rare occasions to “fix rebase hiccups” Version control ain’t a match for a good backup

So? if it removes .git, just clone the project again and you are ok

In that case, you're just relying on your remote backup :-)

Re: Running Claude Code dangerously (safely)

#265

Post by redactsureAI » Thu, Jan 22, 2026, 11:15 PM UTC

eli wrote: post #243

dist-epoch wrote: post #175

Earlier quoted context omitted.

Why do you need to share anything? Code goes through GitHub - VM has it's own repo clone, if you need data files, you mount them read-only in the VM, have a read-write mount for output data.

I'd like to be able to see and edit the code in an IDE

I work every day in a remote node with an IDE. VS code has a really simple extension you can run a full ide with file system control in a remote server. Git clone your files, open up VS code.