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

191–200 of 265 posts

Re: Running Claude Code dangerously (safely)

#191

Post by charcircuit »

corv wrote: post #72

I'm pursuing a different approach: instead of isolating where Claude runs, intercept what it wants to do. Shannot[0] captures intent before execution. Scripts run in a PyPy sandbox that intercepts all system calls - commands and file writes get logged but don't happen. You review in a TUI, approve what's safe, then it actually executes. The trade-off vs VMs: VMs let Claude do anything in isolation, Shannot lets Claud…

>commands and file writes get logged but don't happen. You review in a TUI, approve what's safe, then it actually executes.

This what claude already does out of the box.

Re: Running Claude Code dangerously (safely)

#192

Post by runekaagaard »

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 surprisingly pleasant to create a layered sandbox approach with bubblewrap and Landlock LSM: Landlock for filesystem restrictions (deny-first, only whitelisted paths accessible) and TCP port control (API, git, local dev servers), bubblewrap for mount namespace isolation (/tmp per-project, hiding secrets), and dnsmasq for DNS whitelisting (only essential domains resolve - everything else gets NXDOMAIN).

Re: Running Claude Code dangerously (safely)

#193

Post by devolving-dev »

snowmobile wrote: post #179
devolving-dev wrote: post #144

Earlier quoted context omitted.

Whether driven by fear or by their model weights or whatever, I don't think that the likelihood of an AI agent, at least the current ones like Claude and Codex, acting maliciously to harm my systems is much different than the risk of a human employee doing so. And I think this is the philosophical difference between those who embrace the agents, they view them as akin to humans, while those who sandbox them view them…

Sure, current agents are harmless, but that's due to their low capability, not due to their alignment with human goals. Can you explain why you'd view them as more similar to humans than to computer viruses?

It's just in my personal experience, I ask AI to help me and it seems to do it's best. Sometimes it fails because it's incapable. It's similar to an employee in that regard. Whereas when I install a computer virus it instantly tries to do malicious things to my computer, like steal my money or lock my files or whatever, and it certainly doesn't try to help me with my tasks. So that's the angle that I'm looking at it from. Maybe another good example would be to compare it to some other type of useful software like a web browser. The web browser might contain malicious code and stuff, but I'm not going to read through all of the source code. I haven't even checked if other people have audited the source code. I just feel like the risk of chrome or Firefox messing with my computer is kind of low based on my experience and what people are telling me, so I install it on my computer and give it the necessary permissions.

Re: Running Claude Code dangerously (safely)

#194

Post by jazzyjackson »

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.

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.

Re: Running Claude Code dangerously (safely)

#195

Post by tptacek »

gcr wrote: post #28
loloquwowndueo wrote: post #13

Shellbox.dev and sprites.dev were discussed recently on hacker news, they give you a sandbox machine where it’s likely safe to run coding agents in dangerous mode. Filesystem checkpoint and restore make it easy to recover from even catastrophic mistakes.

What about API calls? What about GitHub trusted CI deploys? One frustrating thing about these solutions is that they’re great to prevent Claude from breaking a machine, but there’s no pervasive sandbox for third party services

This is a fun open problem. We've got stuff coming for it (don't want to hijack the thread, though).

Re: Running Claude Code dangerously (safely)

#196

Post by tptacek »

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'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 especially careful (just making sure it didn't run random bash commands to, like, install a different Emacs or something).

Re: Running Claude Code dangerously (safely)

#197

Post by Finbarr »

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

Re: Running Claude Code dangerously (safely)

#198

Post by metachris »

bonsai_spool wrote: post #119
nunez wrote: post #117

Vagrant is great for Claude! You can also use Lima, a lightweight VM control plane, as it natively works with qemu and Virtualization.Framework. (I think Vagrant does too; it's been a minute since I've tried.) This has traditionally been used for running container engines, but it's great for narrowly-scoped use cases like this. Just need to be careful about how the directory Claude is working with is shared. I copy m…

How are you configuring Lima? Do you have any scripts you use to set up the environments or is this done ad hoc?

I recently wrote a blog post about just that - how to run LLMs in Lima VMs: https://www.metachris.dev/2025/11/sandbox-your-ai-dev-tools-...

Re: Running Claude Code dangerously (safely)

#199

Post by runekaagaard »

tptacek wrote: post #196
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'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…

Configuring Claude Code ... the new init.el ;)

Re: Running Claude Code dangerously (safely)

#200

Post by alphax314 »

Am I the only one who has setup notifications in the terminal so when claude is done and asks for a permission or whatever else it might need the terminal has a red dot and is bouncing? I go back to it respond in two seconds and then switch back to whatever I was doing. It doesnt feel that disruptive that I would want to run it with the —dangerous flag.
Post reply on HN