devvm CLI
devvm gives each project its own virtual machine with the right toolchains, where Claude Code and Codex cannot see your secrets
- 599 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- Creates virtual machines and mounts the project folder into them with write access, and without --clone the agent can change the working tree and .git
- The install script asks for access to Lima, QEMU and /dev/kvm, and network tiers beyond allowlist widen the machine's reach to the internet
Install
- Works in
Manual install
brew trust --formula devvmhq/tap/devvm && brew install devvmhq/tap/devvmOn macOS Homebrew installs Lima too.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Creates virtual machines and mounts the project folder into them with write access, and without --clone the agent can change the working tree and .git
- The install script asks for access to Lima, QEMU and /dev/kvm, and network tiers beyond allowlist widen the machine's reach to the internet
This is third-party code. Review the repository files before installing.
What it does
devvm is a Go command-line tool that spins up an isolated virtual machine for a project folder. Running devvm in a folder detects the toolchains from the project's files, so package.json brings node. It then shows what the VM will get and, after you confirm, creates it and opens a shell at the same path as on your machine. The prompt starts with (devvm), and you run claude, codex, opencode or pi there. Running it again in the same folder opens the same VM. VMs run on Lima, each one is a copy of a base image and starts in seconds. The VM mounts only the project folder. Your GitHub and Claude Code tokens stay on your machine on every network tier, and new VMs default to the allowlist tier that reaches only hosts you approve. The --clone flag gives the VM its own clone of the repository: nothing touches your working tree or .git, and you pull the result with git fetch devvm and review it before merging. Agent settings, skills and MCP servers live in a store of their own, and devvm agent import copies them in from an agent already installed on your machine. Extra image layers include docker, nix and desktop, plus your own from devvm layer new.
Who it is for. Developers who run Claude Code, Codex, opencode or pi with broad permissions and want the agent in a separate sandbox instead of their main system.
Good fit when
- The agent runs commands without confirmations and you need them isolated from your home folder and keys
- The project needs its own toolchains and you do not want them on your main system
- You want to review the agent's work through git fetch devvm before merging into the main branch
- You need a machine with Docker or a desktop inside the sandbox through the docker and desktop layers
Not a fit when
- You are on an Intel Mac: the authors tested only Apple silicon and Linux on arm64 and x86_64
- You need a full isolation guarantee: the docs themselves say no sandbox closes every gap
- You are on Windows: devvm requires macOS 13 or newer, or Linux
Example request
Create a devvm for this project with --clone, run Claude Code inside it and let me review the changes through git fetch devvmLimitations
- Needs macOS 13 or newer, or Linux on arm64 or x86_64, and Lima 2.2 or newer. Intel Macs are not yet tested.
- Before the first VM devvm builds a base image for a few minutes and asks about default VM size and agents.
- Claude Code login is done with devvm agent login claude, and the token stays on your machine.
- The docs warn that no sandbox closes every risk and ask you to read the Staying safe section before trusting a VM with an important project.
How to disable. You can stop and delete a project's VM with devvm commands, and the full list is in the CLI reference at devvm.dev. The program itself is removed through your package manager: brew uninstall devvm on macOS, or deleting the binary the install script placed on Linux. Lima machines and images are removed separately with Lima commands.
FAQ
How do I run Claude Code in a devvm sandbox?
Run devvm in the project folder and confirm the VM, then log in with devvm agent login claude and start claude in the shell whose prompt reads (devvm). The Claude Code token stays on your machine.
What can the devvm virtual machine see on my computer?
Only the project folder, at the same path as yours. Secrets such as GitHub and Claude Code tokens stay on the host on every network tier, and the network is limited to an allowlist by default.
How do I take the agent's work out of devvm?
Create the VM with devvm --clone, then on your machine run git fetch devvm and git log -p main..devvm/main. Changes reach your repository only after you review them.
Which agents run in devvm?
Claude Code, Codex, opencode and pi. Settings, skills and MCP servers live in a store of devvm's own, and devvm agent import brings them over from an agent you already use.
How is devvm different from Docker Sandboxes?
devvm runs Lima virtual machines instead of containers and keeps one VM per project folder. The authors put the comparison with Docker Sandboxes and other tools on the Compared to other tools docs page.
Discussion
No questions or reviews yet.
Related
CLI toolsBrig runs Claude Code and other coding agents inside an isolated microVM on your machine with access to one project only.
clawk is a virtual-environment CLI that snapshots a Linux machine’s memory and disk so running processes can be resumed later.
CLI for microVMs: an isolated virtual machine with its own kernel for agents, sub-second boot, checkpoints and branching.
A CLI that runs Claude Code and Codex in isolated Docker containers with a firewall, worktrees and a no-Dockerfile image.
CLI and app for workspaces: each AI agent gets its own container from a shared devcontainer.json, with an MCP server and a skill
AgentBox runs Claude Code, Codex and Open Code in separate virtual machines on your PC, a self-hosted server or a cloud.
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| devvm (this card) | no | 599 | ||
| Agent-Sandbox | no | key is optional | 232 | another project's sandbox, while devvm builds on Lima virtual machines with a dedicated project folder |
| Ephemeral Sandbox | no | not required | 125 | a throwaway sandbox for one run, while devvm keeps a persistent VM per project folder |
README in short
The README starts with installation through Homebrew or a minisign-signed script, then explains the first run in three steps. Lists of supported toolchains, agents, layers and backend follow, along with a section on working on a clone and an index of the docs pages.