Claude Code Isolation Patterns

[TimJohns]

I'm curious what other folks are doing to use smolvm for isolation of long-running unattended workloads in Claude Code.

Here are some notes from the patterns I'm currently experimenting with this morning, and for illustration purposes this is my simplest "Hello, world!":

smolvm sandbox run \                                 
    --net \
    -e "ANTHROPIC_API_KEY=sk-ant-i-heart-entropy-blahblahblah-redacted" \
    node:22-slim -- \
    npx -y @anthropic-ai/claude-code -p "Just say Hello, World! and exit."

• I'm curious if other folks run Claude Code CLI itself within the smolvm like this? Versus flipping the pattern, and using Claude Code to launch smolvm to run shell scripts and other commands?
• My hello-world sample here relies on the Anthropic API key passed in as an environment variable. Curious if there are other patterns for this, where essentially every launch will need it. I go into more detail on my curiosity about what folks are doing for persistence more generally, below.
• In addition to the Anthropic API key, I'm also passing in narrowly-scoped, task-specific Google Cloud Platform credentials that I'm using for more narrowly-scoped practical operations (not shown in my "hello world" example above) -- for instance, one agent (and SA/set of creds) to deploy to a particular staging environment and another agent (and different SA/set of creds) to monitor the production logs. That's the whole reason I'm experimenting with this - the user-account GCP creds on my laptop that I use all the time are created with the https://en.wikipedia.org/wiki/Principle_of_least_privilege in mind -- but my personal interactive privileges are still much more broadly scoped than I want to hand off to any given long-running subagent, the same way I wouldn't just clone my laptop (and credentials) and hand it over to a dev/operations team. Curious what other folks are doing here, and hoping to inspire folks to post their own command lines and scripts slightly more elaborate than my little "Hello, World!" example above.
• Using node:22-slim (and npx) added some launch/startup time when running in a sandbox, curious what patterns with persistence, containers, and packs other folks are using, and just like the item above, I'm hoping to inspire folks to post their own "Hello World!" and maybe some quick starts.
• I had to manually resize and reformat the VM filesystem (i.e. /Users/tjohns/Library/Application Support/smolvm/storage.raw and /Users/tjohns/Library/Application Support/smolvm/storage.formatted) to get this to work, and the Claude Code analysis indicated resize2fs is in the init script of the rootfs (build-agent-rootfs.sh), but the Rust agent code in mount_storage_disk() does NOT call resize2fs after mounting.. I'm not personally familiar enough with smolvm, MicroVMs, or even containers enough to know whether is is intentional and expected, or a bug/feature improvement worth considering -- but figured I'd include this information in my notes here in case someone else is running into something similar.

[BinSquare]

I'm curious if other folks run Claude Code CLI itself within the smolvm like this? Versus flipping the pattern, and using Claude Code to launch smolvm to run shell scripts and other commands?

smolvm is designed to be flexible intentionally.

There's 2 general patterns I use it and the specific commands i use:

1. Run coding agent inside the microvm. I use smolvm microvm for this kind of workload.
2. Let the coding agent create, use, destroy microVM's from your host machine. I use smolvm sandbox for this kind of workload.

---

My hello-world sample here relies on the Anthropic API key passed in as an environment variable. Curious if there are other patterns for this, where essentially every launch will need it. I go into more detail on my curiosity about what folks are doing for persistence more generally, below.

And yep! That's a valid way to inject api keys.

I personally only use Codex and I just mount this the .codex which has the auth, sessions, histories already setup. So I never have to inject keys or whatever. Here's an example of my .codex path:

(base) binsquare@mac.lan:~/Documents/smolvm (main*) $ ls ~/.codex/
auth.json         history.jsonl     models_cache.json shell_snapshots   sqlite            vendor_imports
config.toml       log               sessions          skills            tmp               version.json

---

Using node:22-slim (and npx) added some launch/startup time when running in a sandbox, curious what patterns with persistence, containers, and packs other folks are using, and just like the item above, I'm hoping to inspire folks to post their own "Hello World!" and maybe some quick starts.

I have not updated code base yet! But state actually persists with the smolVM microvm command. But I also just packed a coding agent into a portable executable .smolmachine :) so there's no need to install anything.

I'll push that change soon!

---

Last comment - that's a bug! It is fixed in the newest commits and I did not run a new build. Will do that shortly

[janzheng]

for env variables, could you use the same tokenizer / masking technique Fly.io Deno sandbox uses: https://news.ycombinator.com/item?id=46874822

https://github.com/superfly/tokenizer

basically you're injecting API tokens on external url requests, so if keys can't ever get exposed if you try to read them

Fly has a blog here: https://fly.io/blog/operationalizing-macaroons/

[zilto]

Hey! I've been exploring smolvm vm for a similar pattern of running CLI agents and the generated code inside the microVM.

However, I'm having trouble with a few things:

• volumes don't seem to work. It notes "Mounts: 1", but I can't see the mounted directory when executing commands or launchign a shell. e.g.

  smolvm vm create --net --volume ./host_dir:/guest_dir sandbox
  smolvm vm start sandbox
  smolvm vm exec --name sandbox -- ls
  # or interactively
  smolvm vm exec --name sandbox -it -- /bin/sh

• I often hit errors Failted to create file/path: No space left on device. Is this associated with the storage: capacity? or overlay:?

I'm on MacOS

[phooq]

For 1, yes I can confirm from my side. Track it here: #18 (comment)

smolvm vm exec --name sandbox -- ls

bin
dev
etc
home
lib
media
mnt
oldroot
opt
proc
root
run
sbin
srv
storage
sys
tmp
usr
var
qiaofu@Fus-MacBook-Pro-Dev workspace % smolvm vm exec --name sandbox -it -- /bin/sh
/ # ls
bin      dev      etc      home     lib      media    mnt      oldroot  opt      proc     root     run      sbin     srv      storage  sys      tmp      usr      var
/ # ls storage/
configs     containers  layers      lost+found  manifests   overlays
/ # ls mnt/
newroot/  overlay/
/ # ls mnt/overlay/
/ # 
/ # 
/ # 

for 2, could you share what steps you take to reproduce it?

[phooq]

@zilto I took a further look at this issue. It has been fixed in the latest main. I guess you were using the 0.1.17 released artifacts.

On my side:

smolvm vm create sandbox --net -v ./smolvm-mount:/guest_dir 
...
smolvm vm start sandbox 
...

smolvm vm exec --name sandbox -it /bin/sh
/ # ls
bin        dev        etc        guest_dir  home       lib        media      mnt        oldroot    opt        proc       root       run        sbin       srv        storage    sys        tmp        usr        var
/ # ls guest_dir/
testfile.txt
/ # 
/ # exit

You can either wait for 0.1.18 release or build the latest by the following commands:

rm -rf dist/*
./scripts/build-agent-rootfs.sh
./scripts/build-dist.sh
./scripts/install-local.sh

Let me know if you still see issues. Apologies

[BinSquare]

+1 to Fu's comment, we fixed the volume issue but will need to cut a new release to distribute it.

And thanks for the comment, we'll fix the bug!: #19

* I often hit errors `Failted to create file/path: No space left on device`. Is this associated with the `storage:` capacity? or `overlay:`?

I'm on MacOS

Basically for smolvm, we follow same pattern as firecracker with 2 disks but we implement it as sparse instead of allocating 20GB from the host right off the bat.

The storage for smolvm has an overlay disk (/dev/vdb) and a storage disk (/dev/vda) to the guest.

The storage disk is used for the oci image layers and container overlays.

The overlay is like the diffs layer (the upper layer of overlayfs in containers) where apk adds, pip installs go to. The user is basically saying they are running out of space in this layer and it's a bug - because i hardcoded it to 2GB. My original thinking was that it's unlikely for people to exceed this, but i just installed both codex + claude code and was able to replicate the same issue.

[BinSquare]

@zilto I've cut a new release with the fixes + verifications here: #19 (comment)

Hope that unblocks you! If you run into any issues or have feature requests, the devs are in this discord: https://discord.gg/vx375Jyn