> 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 commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.

(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)

Once approval fatigue and ongoing permission management kicks in, the temptation is strong to run `--dangerously-skip-permissions`. I think that's what we all want - run agents in a locked-down sandbox where the blast radius of mistakes and/or prompt injection attacks is minimal/acceptable.

I started running Claude Code in a devcontainer with limited file access (repo only) and limited outbound network access (allowlist only) for that reason.

This weekend, I generalized this to work with docker compose. Next up is support for additional agents (Codex, OpenCode, etc). After that, I'd like to force all network access through a proxy running on the host for greater control and logging (currently it uses iptables rules).

This workflow has been working well for me so far.

Still fresh, so may be rough around the edges, but check it out: https://github.com/mattolson/agent-sandbox

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 Claude propose changes to your real system with human approval. Different use cases - VMs for agentic coding, whereas this is for "fix my server" tasks where you want the changes applied but reviewed first.

There's MCP integration for Claude, remote execution via SSH, checkpoint/rollback for undoing mistakes.

Feedback greatly appreciated!

[0] https://github.com/corv89/shannot

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 my Git repo to a container volume to use with Claude (DinD is an issue unless you do something like what Kind did) and rsync my changes back and verify before pushing. This way, I don't have to worry if Claude decides to rewind the reflog or something.

Since everyone tends to present their own solution, I bid you mine:

    sandbox-run npx @anthropic-ai/claude-code

This runs npx (...) transparently inside a Bubblewrap sandbox, exposing only the $PWD. Contrary to many other solutions, it is a few lines of pure POSIX shell.

https://github.com/sandbox-utils/sandbox-run

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 contagious bacteria in your backyard, not really something your neighbors would appreciate.

My approach to safety at the moment is to mostly lean on alignment of the base model. At some point I hope we realize that the effectiveness of an agent is roughly proportional to how much damage it could cause.

I currently apply the same strategy we use in case of the senior developer or CTO going off the deep end. Snapshots of VMs, PITR for databases and file shares, locked down master branches, etc.

I wouldn't spend a bunch of energy inventing an entirely new kind of prison for these agents. I would focus on the same mitigation strategies that could address a malicious human developer. Virtual box on a sensitive host another human is using is not how you'd go about it. Giving the developer a cheap cloud VM or physical host they can completely own is more typical. Locking down at the network is one of the simplest and most effective methods.

Of course it depends on exactly what you're using Claude Code for, but if your use-case involves cloning repos and then running Claude Code on that repo. I would definitely recommend isolating it (same with other similar tools).

There's a load of ways that a repository owner can get an LLM agent to execute code on user's machines so not a good plan to let them run on your main laptop/desktop.

Personally my approach has been put all my agents in a dedicated VM and then provide them a scratch test server with nothing on it, when they need to do something that requires bare metal.

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.

It's a practical approach, I used vagrant many years ago mostly successfully. I also explored the docker-in-docker situation recently while working on my own agentic devcontainer[0]- the tradeoffs are quite serious if you are building a secure sandbox! Data exfil is what worries me most, so I spent quite some time figuring out a decent self-contained interactive firewall. From a DX perspective, devcontainer-integrated IDEs are quite a convenient workflow, though docker has its frustrating behaviours

[0]: https://github.com/replete/agentic-devcontainer

For deploying Claude Code as agent, Cloudflare is also an interesting option.

I needed a way to run Claude marketplace agents via Discord. Problem: agents can execute code, hit APIs, touch the filesystem—the dangerous stuff. Can't do that in a Worker's 30s timeout.

Solution: Worker handles Discord protocol (signature verification, deferred response) and queues the task. Cloudflare Sandbox picks it up with a 15min timeout and runs claude --agent plugin:agent in an isolated container. Discord threads store history, so everything stays stateless. Hono for routing.

This was surprisingly little glue. And the Cloudflare MCP made it a breeze do debug (instead of headbanging against the dashboard). Still working on getting E2E latency down.

Here is what I do: run a container in a folder that has my entire dev environment installed. No VMs needed.

The only access the container has are the folders that are bind mounted from the host’s filesystem. The container gets network access from a transparent proxy.

https://github.com/dogestreet/dev-container

Much more usable than setting up a VM and you can share the same desktop environment as the host.

I just gave it its own user and dir. So I can read and write /agent, but agents can't read or write my homedir.

So I just run agents as the agent user.

I don't need it to have root though. It just installs everything locally.

If I did need root I'd probably just buy a used NUC for $100, and let Claude have the whole box.

I did something similar by just renting a $3 VPS, and getting Claude root there. It sounds bad but I couldn't see any downside. If it blows it up, I can just reset it. And it's really nice having "my own sysadmin." :)

What is the consensus on Claude Code's built-in sandboxing?

https://code.claude.com/docs/en/sandboxing#sandboxing

> Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command with the dangerouslyDisableSandbox parameter.

The ability for the agent itself to decide to disable the sandbox seems like a flaw. But do I understand correctly that this would cause a pause to ask for the user's approval?

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

I've been working on a TUI to make bubblewrap more convenient to use: https://github.com/reubenfirmin/bubblewrap-tui

I'm working on targeting both the curl|bash pattern and coding agents with this (via smart out of the box profiles). Early stages but functional. Feedback and bug reports would be appreciated.

PM for Docker Sandboxes here.

Our next version of Docker Sandboxes will have MicroVM isolation and a Docker instance within for this exact reason. It'll let you use Claude Code + Containers without Docker-in-Docker.

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.

I'm currently using a qemu vm for the codex with the --yolo flag but same thing. I've been also looking at using lima for automating the creation of vms. But it does a few weird/dangerous things like mounting the entire user directory read/write. Which kind of defeats the point. There are ways of turning that off probably but it does a few dangerous/annoying things wrong by default.

But a simple vm and some automation to install developer tools using ansible, nix or whatever you prefer isn't that hard to (vibe) code together. I like Lima but it feels slightly sub-optimal for the job currently.

Some useful things to consider:

- Ssh agent forwarding for authenticating against e.g. git is useful. But maybe don't use the same key that authenticates to your production machines as well ...

- How do you authenticate without a browser? Most AI tools have ways to deal with that but it's slightly tedious to automate during provisioning.

- Making sure all your development tools are there; I use things like sdkman, nvm, bun, etc. And I have my shell preferences and some other tools I like to have around.

- Minimizing time provisioning these vms over and over again. This gets tedious really quickly.

- Keeping the VMs fast is important too. In my projects, build tool performance adds up and AI tools like to call them a lot. So assign enough memory and CPU.

- It would be nice to switch between local and remote/cloud based vms easily.

- Software flexibility; developers are picky about their tools. There is no one size fits all here. Even just deciding on the base image to use for your vm is likely to escalate. I picked debian for what it is worth.

In short, I think there's enough out there that you can pull something together but it still involves quite a bit of DIY. It would be nice if this got easier. And AI tools asking for permission for everything is not a good security model. Because people just turn that off. Sandboxing those things is the way to go. But AI tools need to be able to do enough to work with your software.

Bubblewrap + nixos, much easier: https://github.com/7mind/nix-config/blob/main/modules/hm/dev...

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.

Koyeb has great resources about running Claude Code in sandboxes: https://www.koyeb.com/tutorials/use-claude-agent-sdk-with-ko...

If your system were under version control, so that Claude could do whatever it wanted on its own branch, so to speak, would it still be such a big problem? Because you could just roll back if it really did cause problems, couldn't you?

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.

I'm currently building a Docker dev environment for VSCode (github.com/dg1001/xaresaicoder) usable in a browser and hit the same issue. Without docker-in-docker it works well - I even was able to add transparent proxy in the Docker network to restrict outbound traffic and log all LLM calls (pretty nice in order to document your project). For docker-in-docker development and better security isolation, I'm considering Kata Containers instead of Vagrant. Which gives me real VM-level isolation with minimum perf overhead, while still be able to use my docker stuff. Still on my TODO list though. Has anyone actually run Kata with vs code server? Curious about real-world quirks - I've read that storage snapshot performance can be rough.

I'm using devcontainers for this, and I'm finding that a very good solution (coupled with VSCode).

Is anyone running Claude in a GitHub Codespace container?

There was this HN post[0] last week on a tool for automatically shutting down the codespace container when idle.

[0]https://github.com/wandb/catnip

I have been running two or three Claude’s bare metal with dangerously skip permissions all day every day for two months now. It’s absolutely liberating.

Or...use wsl2 in windows. does the same thing - much much faster.

Windows is the best (sandboxed) linux

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 more security.

Does anybody have experience using microVMs (Firecracker, Kata Containers, etc.) for this use case? Would love to hear your thoughts.

i've low-key been running claude in dangerously skip permissions mode for at least like 4 months now and have yet to be bitten by a truly destructive action. YMMV but i think as long as you're guiding/prompting correctly, and don't just allow write access to your prod account DBs willy nilly, it's mostly fine. just keep an eye on it :shrug:

https://github.com/mensfeld/code-on-incus - check out this project

I'm a fan of https://e2b.dev/

Here's what I do (shameless plug): https://blog.denv.it/posts/im-happy-engineer-now/

This allows you to use Claude Code from your mobile device, in a safe environment (restricted Kubernetes pod)

I run Claude in a Proxmox VM, generally the experience has been great. In my experience it also behaves better than gemini cli, that likes to create files all over the place if set loose (lesson learned to add that requirement to the relevant .md files)

sandbox-exec on MacOS (ie. https://github.com/neko-kai/claude-code-sandbox) seems like the perfect solution to me.

Missing FreeBSD jails in 2026 is kind of weird (hello 1999)...

I think this makes sense but I wonder if firecracker would work better than vagrant for this? I haven't used it before, though. I guess it might if you are trying to run gas town level orchestration.

Just create a new user and setup pip/npm to install locally.

And setup an .env for the project with user/password to access only a dev database.

I'm doing this with a remote VM on exe.dev and it's quite nice. Well, actually with their own coding agent but they have Claude Code preinstalled too.

Syncthing works well for getting a local copy of a directory from the VM.

Does anyone have direct experience with Claude making damaging mistakes in dangerously skip permissions mode? It'd be great to have a sense of what the real world risk is.

How about running Claude as a different user with very limited permissions?

Forgive a naive question, but why not run it on an AWS (or equivalent) instance?

docker has sandboxes for this https://docs.docker.com/ai/sandboxes/

docker sandbox run claude

"At some point I realized that rather than do something else until it finishes, I would constantly check on it to see if it was asking for yet another permission, which felt like it was missing the point of having an agent do stuff"

Why don't Claude Code & other AI agents offer an option to make a sound or trigger a system notification whenever they prompt for approval? I've looked into setting this up, and it seems like I'd have to wire up a script that scrapes terminal output for an approval request. Codex has had a feature request open for a while: https://github.com/openai/codex/issues/3052

Don't all modern OS's have sandboxing? We don't need a full VM (eg, kernel running on virtualized hardware) and the complexity that entails, we just need Claude Code running in the sandbox.

(Maybe I should be asking Claude this)

Edit: someone already built this: https://github.com/neko-kai/claude-code-sandbox

docker sandbox run claude? seems to work for me…

> VirtualBox 7.2.4 shipped with a regression that causes high CPU usage on idle guests. What are the odds.

I have such a love/hate relationship with VirtualBox. It's so useful but so buggy. My current installation has a bug that causes high network latency, but I'm afraid to upgrade in case it introduces new, worse bugs.

VMware is a million times better, but it is also Proprietary™

What about Docker rootless?

I noticed something in Claude across all product surfaces

There's a bug in that it can't output smart quotes “like this”

Sonnet, Opus et al think they output it but something in the pipeline is rewriting it

https://github.com/firasd/vibesbench/blob/main/docs/2026/A/t...

Try it in Claude Code and you'll see what I mean! Very weird

> now you need Docker-in-Docker

Or you can just mount the socket and call docker from within docker.

`useradd claude`

Keeping in mind with Vagrant: if you are using a synced_folder in your host as a source folder in the VM, those files in the synced_folder will be modified on the host.

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 tokens it can (and eventually will when it gets confused）go wipe the shared dev database or the GitHub repo. The author kinda acknowledges this, but it’s glossing over a big chunk of the problem. If it can pus to GitHub, unless you’ve set up your tokens carefully it can delete things too. Having a local isolated test database separate from the shared infrastructure is a matter of a mature dev environment, which is a completely separate thing from how you run Claude. Two of the three examples cited as “no, no, no” are not protected by vagrant or docker or even EC2. It’s what tokens the agent has and needs.

[dead]

[flagged]