Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

Post reply on HN
Print view View original

181–190 of 265 posts

Re: Running Claude Code dangerously (safely)

#181

Post by snowmobile »

theptip wrote: post #147
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…

The point of TFA is that you are not letting it do whatever it wants, you are restricting it to just the subset of files and capabilities that you mount on the VM.

Sure, and right now they aren't very capable, so it's fine. But I'm interested in the mindset going forward. I've read a few stories about people handling radioactive materials at home, they usually explain the precautions they take, but still many would condemn them for the unnecessary risk. Compare it to road racing, whose advocates usually claim they pose no danger to the general public.

Re: Running Claude Code dangerously (safely)

#183

Post by YaeGh8Vo »

In my experience, a simple bubblewrap (Linux) or sandbox-exec (macOS) is probably enough and also much less overhead. LLMs agents are not exploiting kernels to get out of the sandbox. The most common issues are them trying to open PRs, or changing files where they shouldn't.

- https://github.com/numtide/claudebox

Re: Running Claude Code dangerously (safely)

#184

Post by rvz »

YaeGh8Vo wrote: post #183

In my experience, a simple bubblewrap (Linux) or sandbox-exec (macOS) is probably enough and also much less overhead. LLMs agents are not exploiting kernels to get out of the sandbox. The most common issues are them trying to open PRs, or changing files where they shouldn't. - https://github.com/numtide/claudebox

> LLMs agents are not exploiting kernels to get out of the sandbox.

You can't assume that.

Attackers with LLMs have enough capabilities to engineer them to build exploits for kernel vulnerabilities [0] or to bypass sandboxes to exfiltrate data [0] in covert ways.

It is completely possible to craft a chained attack for an agent to bypass sandboxes even with or without a kernel exploit.

From [0] and [1]

[0] https://sean.heelan.io/2026/01/18/on-the-coming-industrialis...

[1] https://www.promptarmor.com/resources/claude-cowork-exfiltra...

Re: Running Claude Code dangerously (safely)

#185

Post by giancarlostoro »

icedchai wrote: post #165
giancarlostoro wrote: post #159

Earlier quoted context omitted.

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.

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

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.

Re: Running Claude Code dangerously (safely)

#188

Post by embedding-shape »

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…

Doesn't this assume you bi-directionally share directories between the host or the VM? Or how would the AI inside the VM be able to write to your .git repository or Vagrantfile? That's not the default setup with VMs (AFAIK, you need to explicitly use "shared directories" or similar), nor should you do that if you're trying to use VM for containment of something.

I basically do something like "take snapshot -> run tiny vm -> let agent do what it does -> take snapshot -> look at diff" for each change, restarting if it doesn't give me what I wanted, or I misdirected it somehow. But there is no automatic sync of files, that'd defeat the entire point of putting it into a VM in the first place, wouldn't it?

Re: Running Claude Code dangerously (safely)

#190

Post by matltc »

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.

Post reply on HN