开源沙箱工具 Devvm.dev 发布，为每个项目提供隔离虚拟机

One VM for every project

An isolated sandbox with your project’s toolchain, ready for you or a coding agent to start coding.

On your machine, you run devvm in ~/web, and ~/.ssh, ~/.aws and ~/Documents stay out of the VM. In the VM's shell, whose prompt starts with (devvm), you run claude: the agent runs there, with the project folder mounted read-write and your agents' skills and settings read-only. Its network goes through a proxy on your machine, which adds your token and lets out to the internet only what its allowlist allows.

Quick start

1. Go to your project

Open a terminal and cd into any project folder.

In a terminal on your machine, you type cd ~/some-project.

2. Run devvm

devvm shows what the new VM gets. Confirm to make it, or customize it.

You type devvm, and it shows what the folder's new VM gets: the toolchain node, the agent claude, its size and the network tier allowlist. It asks Customize it? [y/N], and you press enter to make the VM.

3. Start your agent

devvm opens a shell in the VM, whose prompt starts with (devvm), so start your agent there.

In the VM's shell, whose prompt starts with (devvm), you type claude.

Claude Code needs your Claude login before its first start, which devvm agent login claude makes from the VM and keeps on your machine (your first VM). The next time you run devvm in the folder, it opens the same VM, and devvm tools adds an agent to a VM you already have.

What’s supported

Toolchains

devvm chooses the toolchains your project’s files call for, and you can choose more when you customize a new VM or name them with --tools (toolchains).

A folder, ~/web, with package.json and pyproject.toml gets node and python: devvm reads the folder's files.

Coding agents

Claude Code, Codex and opencode run in the VM. Choose one when you customize a new VM, or choose them for every new VM in devvm setup (coding agents).

A terminal in a VM runs claude in ~/web. claude, codex and opencode are ready in it.

Layers

devvm ships the docker, nix and desktop layers, which you choose when you customize a new VM, and devvm layer new creates your own custom layers you can apply to any of your VMs (layers).

The image docker+nix is the nix layer on the docker layer, on base. docker, nix and desktop are the built-in layers.

Why use devvm?

Developers face attacks every day, such as supply chain attacks, leaked secrets, prompt injections and rogue agents.
A sandbox limits the blast radius of an attack to what’s inside it.
You know you should run your code and agents in a sandbox, but most tools need configuration and setup that’s hard to get right.
devvm ships with sensible defaults so you can start coding in a sandbox with a single command.

Without devvm, a prompt injection, leaked secrets, a supply chain attack and a rogue agent reach your machine one after another, and each one compromises what it reaches: the project, ~/web, then ~/.aws, ~/.ssh and another project, ~/api. With devvm, the project is in a VM, and the same four attacks reach the VM. Each one's path toward your machine ends at the VM's border, so ~/.ssh, ~/.aws and ~/api stay untouched.

Developer ready, zero config

The base image comes with optional extras that you choose, such as oh-my-bash, fzf, zoxide (z), tree and tldr.
Every VM gets your git name and email, so the commits made in it are authored by you or your agent.
Ports forward on their own, so a dev server on :5173 in the VM opens at localhost:5173 on your machine (ports).
devvm code opens the VM in VS Code over Remote-SSH (devvm code).

In the VM devvm-web, npm run dev is ready on :5173, and a browser on your machine opens it at localhost:5173. devvm code opens the VM in your editor over SSH. A commit made in the VM has you as its author.

Isolated sandbox

The VM mounts your project folder at the same path. Apart from your agents’ settings from devvm’s own store, which it gets read-only, it sees nothing else in your home folder (what a VM can reach).
New VMs get the allowlist network tier by default, so they reach only an allowlist of hosts, through a proxy on your machine. You can choose a looser tier, internet or open, or a stricter one, none.
On macOS, devvm locks .git’s hooks and config, so the VM can’t change what git runs on your machine (.git protection).
With --clone, the VM works on a clone of the repo of its own instead of your folder, so nothing in it can touch your working tree or .git, and its work reaches your repo only when you fetch it.
No sandbox closes every gap, so attack vectors lists what’s left open, and staying safe lists the habits that close most of it.

On your machine, ~/.ssh, ~/.aws and ~/Documents aren't mounted. Only the project folder, ~/web, goes into its VM, read-write, where .git is locked. The VM's network goes through a proxy on your machine, which lets out to the internet only what its allowlist allows.

Ready in seconds

The first VM builds a base image, and every later VM is a copy of it that starts in seconds (images).
devvm builds each version of a toolchain once and shares it read-only, so all VMs use the same copy (shared tools).

The base image is built once. Each VM, devvm-web, devvm-api and devvm-cli, is a copy of it, up in seconds. node, python, go, rust and claude are shared between them, read-only.

Made for coding agents

The agent runs in the VM, so an attack on it stays in the sandbox. It gets your settings, skills and MCP servers but never your history (coding agents).
On every network tier, their secrets, such as your Claude Code token and your Codex login, stay on your machine, because the VM gets placeholders and devvm’s proxy puts the real ones into its requests on the way out.

Your agents' skills are mounted into the VM read-only, their settings and MCP servers copied in, for claude, codex and opencode. Your history stays on your machine. Your token stays on your machine: the VM has a placeholder, and the proxy adds the token on the way to the API.

Make it yours

Your own layers are setup scripts that devvm builds into an image: devvm layer new mailpit starts one, and devvm --layers mailpit makes a VM with it (your own layers).
devvm setup --layers gives every new VM the layers you choose, so your shell setup, aliases or dotfiles can go in a layer of your own that each VM gets unless you leave it out (extras of your own).
--from starts the base image from a container image instead of Ubuntu’s, such as node:24 or your team’s own (starting from a container image).
When the project has a devcontainer.json, devvm sets up its VM from the file’s container image, ports, environment and commands (devcontainer.json).

A stack: the base image at the bottom, with your features, dotfiles and aliases, built in; your layer, mailpit, on it; and on top the VM devvm-web, made with node+mailpit. A container image, node:24, starts the base image with --from.

FAQ

What does it run on?

devvm runs on macOS and on Linux, on arm64 or x86_64. It needs Lima, which runs the VMs with Apple’s Virtualization framework on macOS and QEMU on Linux (backends). Homebrew installs Lima along with devvm, and on Linux, Lima also needs QEMU and access to /dev/kvm. Installing lists every requirement, and known limits lists what Linux hosts lack, such as .git protection.

Does the agent run on my machine?

No. You start the agent in the VM’s shell, so it runs in the VM, and you never install it on your machine. There it sees only what the VM can reach.

Is it free?

Yes. devvm is open source under the MIT license.

Start coding in a sandbox

Install devvm, then run devvm in any project folder.

Install Read the docs