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.

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.

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

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.

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

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?

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.

If you're on a Linux or Unix OS, a chroot jail might be a more lightweight solution. the chroot command essentially makes the chrooted directory look like the root dir. You need to set up all the directories claude can access (like /usr/bin or whatever). I haven't tried this yet, but I don't see any reason it wouldn't work. This solution would protect files outside your project from getting trashed, but not malicious data exfiltration.

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.