The pitch is simple: every project gets its own VM, your coding agent runs inside it, and your SSH keys, AWS credentials, and other project folders stay outside the blast radius. devvm, an MIT-licensed CLI tool, uses Lima (Apple's Virtualization framework on macOS, QEMU on Linux) to spin up lightweight VMs that mount only the target project folder read-write. Agent tokens never enter the VM — a host-side proxy injects them into outbound API requests, and a network allowlist controls what the VM can reach. The security model is the real product here. Supply chain attacks, prompt injections, leaked secrets, and rogue agent behavior are all contained to the VM boundary. The .git hooks and config directory are locked on macOS so a compromised VM can't modify what git runs on the host. A --clone flag goes further: the agent works on a separate repo clone, and nothing touches the host working tree until the developer explicitly fetches. Agent skills and settings mount read-only; history stays on the host machine entirely. The developer experience layer is designed to eliminate the setup tax that kills adoption of sandbox tools. devvm auto-detects toolchains from project files — a folder with package.json and pyproject.toml gets node and python without configuration. Claude Code, Codex, and opencode are supported as coding agents. Ports auto-forward, git identity propagates, VS Code connects over Remote-SSH. The base image builds once; subsequent VMs spin up in seconds as copies. Customization runs through a layer system. Built-in layers include docker, nix, and desktop. Users can create custom layers via devvm layer new, which are setup scripts baked into images. The --from flag lets you start from any container image instead of Ubuntu. devcontainer.json support means existing Dev Container configurations work without migration. Network tiers range from none (fully airgapped) to open (unrestricted), with allowlist as the default. The threat model is honest about its limits. The docs explicitly list remaining attack vectors and publish a 'staying safe' guide of operational habits that close residual gaps. This is unusual — most developer tools market invulnerability rather than transparent risk disclosure. The architecture makes a real tradeoff: you accept VM overhead in exchange for a hard boundary between your agent's runtime and your credentials. The competitive context matters. As coding agents gain autonomy — running commands, installing packages, making network requests — the surface area for damage scales with capability. Docker-based sandboxes exist but require manual configuration that most developers skip. devvm's bet is that a single-command UX with sensible defaults will get developers into sandboxes who otherwise wouldn't bother. The MIT license and open-source model mean no vendor lock-in or usage-based extraction. The gap to watch is Linux parity. macOS gets .git protection and the Virtualization framework; Linux relies on QEMU and /dev/kvm access with some features missing. Multi-agent orchestration across VMs isn't addressed — each VM is a single-agent boundary. Whether this architecture holds as agents start coordinating across repositories and services is the open question.
