Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

141–150 of 265 posts

Re: Running Claude Code dangerously (safely)

#142

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…

Try asking the latest Claude models about self replicating software and see what happens...

(GPT recently changed its attitude on this subject too which is very interesting.)

The most interesting part is that you will be given the option to downgrade the conversation to an older model. Implying that there was a step change in capability on this front in recent months.

Re: Running Claude Code dangerously (safely)

#143
post #66

I just learned that you can run `claude setup-token` to generate a long-lived token. Then you can set it via `CLAUDE_CODE_OAUTH_TOKEN` as a reusable token. Pretty useful when I'm running it in isolated environment.

yes! just don't forget to `RUN echo '{"hasCompletedOnboarding": true}' > /home/user/.claude.json` otherwise your claude will ask how to authenticate on startup, ignoring the OAUTH token

Re: Running Claude Code dangerously (safely)

#144

Earlier quoted context omitted.

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…

I do not believe that LLMs fear punishment like human employees do.

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 as akin to computer viruses that you study within a sandbox. It seems to me that the human analogy is more accurate, but I can see arguments for the other position.

Re: Running Claude Code dangerously (safely)

#145
I use Development containers (dev-containers) as demonstrated by Claude Code's docs https://code.claude.com/docs/en/devcontainer

It all integrates nicely with VS Code. It has a firewall script and you spin up your database within the docker compose file so it has full access to a postgres instance. I can share my full setup if anyone needs it.

Re: Running Claude Code dangerously (safely)

#146

Earlier quoted context omitted.

This could be avoided by aliasing rm to something else that stops you from deleting stupid things like your entire home directory / partition root.

What if the LLM detects this, and chooses to run /bin/rm directly? Or worse, writes a program that calls unlink.

I mean, you can always purge /bin/rm, but at this point since you're not satisfied, sounds like you want SELinux ;)

If Claude is writing a program to go that low level I'd pay money to watch that.

Re: Running Claude Code dangerously (safely)

#147

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.

Re: Running Claude Code dangerously (safely)

#148

  > So now you need Docker-in-Docker, which means --privileged mode, which defeats the entire purpose of sandboxing.
  > That means trading “Claude might mess up my filesystem” for “Claude has root-level access to my container runtime.”
A Vagrant VM is exactly the same thing, just without Docker. The benefit of Docker is you've got an entire ecosystem of tooling and customized containers to benefit from, easier to maintain than a Vagrantfile, and no waiting for "initialization" on first booting a Vagrant box.

On both Linux and MacOS, use this:

  # Build 'claude' VM and Docker context
  
  $ colima start --profile claude --vm-type=qemu
  $ docker context create claude --docker "host=unix://$HOME/.colima/claude/docker.sock"
  $ docker context use claude
  
  # Start DinD, pass through ports 8080 and 8443, and mount one host directory (for a Git repo)
  
  $ docker run -d --name dind-lab --privileged -e DOCKER_TLS_CERTDIR= -v dind-lab-data:/var/lib/docker \
    -p 8080:8080 -p 8443:8443 -v /home/MYUSER/GITDIR:/mnt/host/home/MYUSER/GITDIR \
    docker:27-dind
  $ docker run --rm -it -e DOCKER_HOST=tcp://127.0.0.1:2375 \
    -p 8080:8080 -p 8443:8443 -v /mnt/host/home/MYUSER/GITDIR:/home/MYUSER/GITDIR \
    ubuntu:24.04 bash

  # Or if you don't want to pass-through ports w/ DinD twice, use its network namespace directly
  #  ( docker run --rm -it -e DOCKER_HOST=tcp://127.0.0.1:2375 --network container:dind-lab .... )

Your normal default Docker context remains safe for normal use, and the "dangerous" context of claude euns in a different VM. If Claude destroys its container's VM, just delete it (colima stop claude; colima delete claude) and remake it.

You could do rootless Docker/Podman, but there's a lot of broken stuff to deal with that will just distract the AI.

Re: Running Claude Code dangerously (safely)

#149
I have been running dangerously, but I always make sure to start a new session, have claude read the docs (I have already generated) related to the project in question, and then scope the work to just those things in the current sandbox. It can technically go outside of the sandbox in this mode, but I've never had it happen.

IMO, if you are not running in the dangerous mode then you are really missing out on one of the best aspects of claude code- its ability to iterate. If you have to confirm each iteration then it's just not practical.

Re: Running Claude Code dangerously (safely)

#150

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

ec2 node?
Post reply on HN