Running Claude Code dangerously (safely) • Hacker News Board

Re: Running Claude Code dangerously (safely)

#251

Post by embedding-shape » Wed, Jan 21, 2026, 9:49 AM UTC

pluralmonad wrote: post #241

embedding-shape wrote: post #215

Earlier quoted context omitted.

That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff. With new realities, new workflows have to be adopted. Once malware…

Or just use a separate user?

That's another option. Or containers. Or cloud hosts. Point is to stop doing bidirectional syncing of directories when you're trying to do isolation.

Re: Running Claude Code dangerously (safely)

#252

Post by Havoc » Wed, Jan 21, 2026, 9:59 AM UTC

nuke-web3 wrote: post #240

Havoc wrote: post #212

I 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?

Tried various routes. Currently using bash scripts straight against the proxmox host. So lots of this

pct exec $CTID -- sh -c "mkdir test"

I've got a script that makes an arch lxc and turns it into a template.

And then bash scripts that deploys it with whatever custom stuff is needed (volume mounts, podman, files pushed into container etc).

Also a pacoloco server (arch/pacman cache) so that all the building and updating for everything is fast & not hitting the upstreams unnecessarily.

Terraform or Ansible also works for this but decided bash is ultimately less moving parts

Re: Running Claude Code dangerously (safely)

#253

Post by lossyalgo » Wed, Jan 21, 2026, 10:54 AM UTC

matltc wrote: post #190

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.

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

Re: Running Claude Code dangerously (safely)

#254

Post by boppo1 » Wed, Jan 21, 2026, 10:54 AM UTC

lucasluitjes wrote: post #118

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

Eh, I stuck it in a docker container with pass-thru to my repo directory and I feel pretty safe about letting it fly.

Then again I dont work on anything serious.

Re: Running Claude Code dangerously (safely)

#255

Post by lucasluitjes » Wed, Jan 21, 2026, 12:34 PM UTC

embedding-shape wrote: post #215

lucasluitjes wrote: post #208

Earlier quoted context omitted.

It's the default behaviour for Vagrant. You put a Vagrantfile in your repo, run `vagrant up` and it creates a VM with the repo folder shared r+w to `/vagrant` in the VM.

That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff. With new realities, new workflows have to be adopted. Once malware…

Agree with all of that, especially modern supply chain risk (imho the more important reason to opt for VM isolation rather than containerization). But the original article specifically talks Vagrant as an isolation solution, and describes it as not protecting against VM escape, but also that guest-to-host 0day is rare.

Hence pointing out that VM escape is a lot easier than that if your VM management tool syncs folders the way that Vagrant does by default.

Re: Running Claude Code dangerously (safely)

#256

Post by xmcqdpt2 » Wed, Jan 21, 2026, 2:31 PM UTC

This also doesn't protect from a "trusting trust" attack where the LLM read my webpage and gets tricked into inserting a vulnerability in the application itself working on.

I feel like the only good sandboxing at this point is one that also blocks generic web access.

Re: Running Claude Code dangerously (safely)

#257

Post by tptacek » Wed, Jan 21, 2026, 3:48 PM UTC

runekaagaard wrote: post #249

tptacek wrote: post #196

Earlier quoted context omitted.

I've been working for the past several weeks in an environment where it's easy and safe to give different claudes yolo-mode, but yesterday I needed to build an Emacs TRAMP plugin, and I had to do that on my local development NUC. I am extremely spoiled for yolo-mode, because even just yes-ok'ing all the elisp fragments claude came up with was exasperating, the whole experience was draining, and that was me not being…

... also interested. What would one build an Emacs TRAMP plugin for? :)

Directly editing files on a remote VM that happens to have an API for directly accessing files.

Re: Running Claude Code dangerously (safely)

#258

Post by pluralmonad » Wed, Jan 21, 2026, 4:16 PM UTC

devolving-dev wrote: post #127

snowmobile wrote: post #121

Bit of a wider discussion, but how do you all feel about the fact that you're letting a program use your computer to do whatever it wants without you knowing? I know right now LLMs aren't overly capable, but if you'd apply this same mindset to an AGI, you'd probably very quickly have some paperclip-maximizing issues where it starts hacking into other systems or similar. It's sort of akin to running experiments on con…

Don't you have the same issue when you hire an employee and give them access to your systems? If the AI seems capable of avoiding harm and motivated to avoid harm, then the risk of giving it access is probably not greater than the expected benefit. Employees are also trying to maximize paperclips in a sense, they want to make as much money as possible. So in that sense it seems that AI is actually more aligned with m…

Its been pretty well documented that LLMs can be social engineered as easily as a toddler. Equating the risk to that of a human employee seems wrong. I'm sure the safeguards will improve, but for now the risk is still there.

Re: Running Claude Code dangerously (safely)

#259

Post by FourSigma » Wed, Jan 21, 2026, 5:52 PM UTC

fwystup wrote: post #158

FourSigma wrote: post #86

I've been exploring this space. There are some use cases where I'd love to run an isolated Claude agent asynchronously. I think running Docker in rootless mode might solve some of the OP's concerns—I believe Podman does this implicitly. Also, there are tools like Kaniko that does not need Docker to create container images. You can also try changing the underlying container runtime to something like gVisor if you want…

Posted almost at the same time about Kata. I'm trying to use Kata as replacement for the standard docker runtime (since I already have a tool based on docker). The idea is to simply use the runtime flag (after kata install): docker run -d --runtime=kata -p 8080:8080 codercom/code-server:latest Hope this works, with this I could keep my existing docker setup.

That is a great idea. Have you looked into Docker's Sandbox feature?

Re: Running Claude Code dangerously (safely)

#260

Post by vidarh » Thu, Jan 22, 2026, 12:23 AM UTC

NitpickLawyer wrote: post #95

jermaustin1 wrote: post #75

Earlier quoted context omitted.

I've often found that LLMs don't listen to "Don't do" commands with anywhere near the same gusto as "Do" commands.

People don't usually think about pink elephants, unless you ask them not to think about pink elephants :)

Indeed, a whole lot of criticisms against LLMs are involve in part how they increasingly act too much like humans in ways people don't like from their computers...