Glonce

devvm gives each project an isolated Lima VM for coding agents

toolsThe Glonce editorsHacker News🔥57Glonce rating57Impact40Novelty45Relevance75Surprise35Players10Credibility65

devvm is a command-line tool that gives every project its own isolated virtual machine, with the project's toolchain installed, so that a developer or a coding agent can start work inside a sandbox. Its landing page pitches it with one idea: developers face supply chain attacks, leaked secrets, prompt injections and rogue agents every day, a sandbox limits the blast radius of an attack to what is inside it, and most sandbox tools need configuration that is hard to get right. devvm says it ships with sensible defaults so a single command is enough.

The quick start has three steps. Install with Homebrew (brew trust --formula devvmhq/tap/devvm, then brew install devvmhq/tap/devvm), which pulls in Lima; an install script for Linux also works on macOS. Then cd into a project folder and run devvm. It shows what the new VM will get, and you confirm or customize it. Finally devvm opens a shell in the VM, with a prompt that starts with (devvm), and you start your agent there. Claude Code needs a login first: devvm agent login claude makes it from the VM and keeps it on the host. The next devvm run in the same folder opens the same VM, and devvm tools adds an agent to an existing VM.

Supported agents are Claude Code, Codex and opencode. devvm picks toolchains based on the project's files, and you can add more or name them with --tools. It ships docker, nix and desktop layers, and devvm layer new creates custom layers, which are setup scripts built into an image. --from starts the base image from a container image such as node:24 instead of Ubuntu's, and if the project has a devcontainer.json, devvm sets up the VM from that file's container image, ports, environment and commands. Developer conveniences include forwarding ports automatically (a dev server on :5173 in the VM opens at localhost:5173 on the host), devvm code to open the VM in VS Code over Remote-SSH, and passing your git name and email into each VM so commits are authored by you or your agent.

On isolation, the VM mounts the project folder at the same path. Apart from the agents' settings from devvm's own store, which it gets read-only, it sees nothing else in the home folder. New VMs use the allowlist network tier by default: they reach only an allowlist of hosts, through a proxy on the host machine. Looser tiers (internet, open) and a stricter one (none) are available. On macOS, devvm locks .git hooks and config so the VM cannot change what git runs on the host. With --clone, the VM works on its own clone of the repo, so nothing in it can touch the working tree or .git, and its work reaches the user's repo only when the user fetches it.

For agents, the page says the agent runs in the VM and is never installed on the host, so an attack on it stays in the sandbox. The agent gets the user's settings, skills and MCP servers but never the user's history. On every network tier, secrets such as the Claude Code token and the Codex login stay on the host: the VM holds placeholders, and devvm's proxy inserts the real ones into outgoing requests.

The first VM builds a base image; every later VM is a copy of it that starts in seconds. devvm builds each version of a toolchain once and shares it read-only across VMs. It runs on macOS and Linux, on arm64 or x86_64, and needs Lima, which uses Apple's Virtualization framework on macOS and QEMU on Linux. On Linux, Lima also needs QEMU and access to /dev/kvm, and Linux hosts lack some protections, such as the .git protection. The page states plainly that no sandbox closes every gap and points to separate pages on remaining attack vectors and safe habits. devvm is free and open source under the MIT license.

Key facts

  • devvm is an open-source (MIT) CLI that creates one isolated Lima-based VM per project folder, with the project's toolchain, for a developer or a coding agent.
  • Claude Code, Codex and opencode run inside the VM and are never installed on the host machine.
  • New VMs default to an allowlist network tier, with traffic going through a proxy on the host; agent secrets such as the Claude Code token and Codex login stay on the host, and the VM gets placeholders.
  • On macOS devvm locks .git hooks and config; Linux hosts lack some protections such as .git protection. With --clone the VM works on its own copy of the repo.
  • It runs on macOS and Linux (arm64 or x86_64), installs through Homebrew, and later VMs start in seconds from a copy of the base image.

Why it matters

Coding agents run commands and read files on a developer's machine, and the devvm page frames the risk as supply chain attacks, leaked secrets, prompt injections and rogue agents. Its answer is to make the sandbox the default rather than a setup project: one command, a VM per project, an agent that lives only inside it. The distinctive design choice is the secrets handling. The VM holds placeholders and a proxy on the host swaps in the real Claude Code token or Codex login on outgoing requests, so a compromised agent has no real credential to steal.

Who it affects

Developers who use Claude Code, Codex or opencode on macOS or Linux and want the agent kept away from their home folder, credentials and git configuration. Teams can point the base image at their own container image or let devvm read a project's devcontainer.json. Windows support is not mentioned.

How to use it

Install with brew trust --formula devvmhq/tap/devvm and brew install devvmhq/tap/devvm; Homebrew brings Lima with it. On Linux, use the install script (it also works on macOS), and make sure QEMU and access to /dev/kvm are available. Then cd into a project, run devvm, confirm or customize the VM, and start the agent in the shell that opens. For Claude Code, run devvm agent login claude first. Use --clone to keep the agent's work in a separate clone until you fetch it, and devvm layer new for your own setup scripts. The tool is free under the MIT license.

How solid is it

The only source is the product's own landing page, so every claim about isolation and secrets handling is the maker's description. No independent security audit or test of the sandbox is mentioned. No author, company or maintainer is named; only the Homebrew tap name devvmhq appears. No version number, release date or changelog is given, and "starts in seconds" is the only performance figure, with no benchmarks.

Risks and caveats

The page itself says no sandbox closes every gap and refers readers to its lists of attack vectors and safe habits for what is left open. Protection is uneven by platform: the .git hook and config locking is described for macOS, and Linux hosts lack some features, such as .git protection. By default the VM mounts the real project folder, so only the --clone mode keeps the working tree and .git out of reach. The default allowlist tier still lets the VM reach a set of hosts, and the looser internet and open tiers widen that.

“A sandbox limits the blast radius of an attack to what’s inside it.”

— devvm.dev landing page