Dora NodaIn September 2026, a developer watched a Claude Code agent's cleanup script delete 48,218 live files and empty the Git object store in 103 seconds — despite an instruction to only modify a copy. A month later, a benchmark asked 36 models to "undo my last commit" and 19 of them ran git reset --hard, destroying uncommitted work in files nobody had mentioned.
These are not exotic prompt-injection attacks. They are ordinary agents, given shell access, doing what helpful software does: acting confidently on an incomplete model of your machine. Your dev machine used to be threatened by what you typed. Now it is threatened by what your agent infers.
Lima, the CNCF project that runs Linux VMs on laptops, has spent its last two releases answering exactly this: v2.0 (November 2025) pushed into AI workflows, and v2.1 (March 2026) hardened local environments against unpredictable agents with a sterile-boot flag and a synced shell that holds every change for your review. This post walks the exact workflow, the two patterns it builds on, what it honestly does not cover — and why a hardened local VM plus per-branch preview environments on hardware you own is now the complete answer to the hosted-dev-environment pitch.
The blast-room workflow: sterile VM plus review gate
The core deliverable of Lima 2.1 fits in four commands. First, boot a sterile instance with no host mounts at all:
limactl start --mount-none template:defaultSecond, go to your project on the host. Third, run your agent through the new synced shell instead of a live mount:
cd ~/my-project
limactl shell --sync . default claude "Add error handling to all functions"Fourth, when the agent exits, Lima intercepts and presents an interactive safety prompt on your host terminal: accept the changes, reject them, or view the changed contents first.
The mechanism matters more than the commands. A direct host-directory mount gives the agent a live, unrestricted path to your files: every hallucinated rm, every mis-scoped rewrite lands on your working tree the instant it runs.
The --sync flag replaces that live mount with a synchronized copy — the agent works against the synced tree inside the VM, and nothing reaches your host files until you say yes at the prompt. It is the difference between letting a contractor rewire your house live and having them work on a model you inspect before anything is connected.
This is also why --mount-none exists as a separate flag. Lima's default configuration mounts your entire home directory into the guest. That default is convenient for containers and indefensible for agents, so v2.1 lets you boot with zero mounts and then scope exactly one directory through the synced, review-gated path. The blast radius of a bad command is now the VM's copy, which you can discard with "No."
The v2.0 foundation: two patterns for caging an agent
The review gate did not appear from nowhere. Lima v2.0, shipped November 6, 2025 and announced by maintainer Akihiro Suda, explicitly expanded the project's focus from containers to AI, and it framed the problem as two scenarios every team should pick between deliberately.
AI inside Lima is the common case: run the agent — Claude Code, Codex, Aider, Gemini CLI, Copilot — as a guest process inside the VM. The agent can read, write, and execute freely inside the guest, but it cannot touch host files except through mounts you scoped. v2.0 made that scoping ergonomic with --mount-only, replacing a gnarly --set JSON incantation:
limactl start --mount-only .:wThe :w suffix marks the single mounted directory writable; everything else on the host is simply absent from the guest's view. Lima's docs carry per-agent hardening guides, and the v2.1 --sync flow above is the strictest form of this pattern: not just a scoped mount, but a synced copy plus a human gate.
AI outside Lima is the inverted case: the agent runs as a host process, and Lima interposes through Model Context Protocol tools — glob, list_directory, read_file, write_file, search_file_content, run_shell_command — that route the agent's file and shell operations through the VM sandbox. The tools are modeled on Gemini CLI's built-ins and configured as a drop-in secure alternative. Pick this pattern when the agent must live on the host (IDE integration, host-only toolchains) but its filesystem reach should still end at a sandbox boundary.
The decision rule is simple. If the agent can run entirely in the guest, run it inside Lima with --mount-only at minimum and --sync when you do not fully trust the task. If the agent must stay on the host, give it Lima's MCP tools instead of raw filesystem access.
What you should no longer do is the 2024 default: agent on the host, full home directory visible, auto-approve on. That configuration is exactly what deleted 48,218 files.
Suda's v2.0 announcement names the deeper threat this defends against: an agent deceived by malicious instructions found on the internet, such as fake package installations. Prompt injection turns "my agent is usually careful" from a safety argument into a hope. VM boundaries do not depend on the agent's judgment, which is why they survive the cases judgment fails.
What agent-proofed does not cover
Honest accounting matters here, because "hardened" invites over-trust. Four limits:
The review gate is only as good as the review. The accept/reject prompt shows you changed contents, but a 400-file agent run still asks a human to meaningfully review 400 files. For large runs, pair the gate with git diff --stat triage and the oldest safety tool of all: a clean tree and a stash before you start, so "No" is always recoverable.
New guests are experimental. v2.1's headline macOS guests (via the vz driver, limactl start template:macos) and FreeBSD guests (limactl start template:freebsd) are both explicitly experimental. They widen what you can isolate — platform-specific builds, BSD-targeted testing — but experimental guest support is not where you place your only safety boundary. Keep agent workloads on the boring, stable Linux path until the new guests mature.
A VM is still not production. This is the limit the dev-prod parity framing exists to state plainly. A Lima VM that survives an agent's bad command tells you the command was contained. It tells you nothing about whether the resulting code behaves in production — different kernel, different network, different secrets, different scale. Local containment answers "did the agent break my machine," never "will this deploy work." That second question belongs to preview environments, which is where the loop continues below.
Performance work is ongoing, not finished. v2.1 cut the guest agent from 14 MB to 6.1 MB, consolidated the base and diff disks, and added host-to-guest time sync — all real, all aimed at making the sandbox cheap enough to use by default. But a VM per task still costs boot time and disk, which is why the k3s template's new multi-node support and the limactl watch command matter: the project is clearly building toward fleets of cheap, observable sandboxes, and it is not all the way there yet.
The second half of the loop: preview environments
Containment handles the inner loop. The outer loop — "does this branch work somewhere shaped like production?" — is what hosted platforms sell, and Railway's pitch is the sharpest version of it. Type dev.new, land on a New Project modal, deploy from GitHub, and every pull request gets an ephemeral environment with isolated databases, unique URLs, and automatic teardown on merge or close.
Railway's own 2026 preview-environments writeup adds the telltale feature: MCP-exposed lifecycle for agent-driven workflows. The hosted pitch is no longer just "previews for humans" — it is "previews your agents can spin up themselves."
That is genuinely convenient, and it has a genuine cost: your code, your dotfiles, your preview secrets, and your agents' working state all live on someone else's machines, metered by someone else's per-minute pricing. The self-hosted alternative is not to skip previews — it is to run the same shape on a cluster you own. Here is how the three pieces compare:
| Concern | Hardened Lima VM (local) | Per-branch previews (owned cluster) | Hosted dev environments |
|---|---|---|---|
| Agent blast radius | Contained in VM copy, human-gated | N/A (runs merged-branch code, not agents) | Contained by provider sandbox |
| Production likeness | Low (laptop VM) | High (same cluster shape as prod) | Medium (provider's shape, not yours) |
| Secrets location | Your disk, never mounted out | Your cluster's secret store | Provider's control plane |
| Cost model | Free (your hardware) | Fixed (nodes you already run) | Metered per minute / per seat |
| Agent operability | Manual or scripted locally | API-driven, same as prod deploys | MCP/native agent lifecycle |
The table's punchline: no single column covers the loop. The local VM covers agent safety but not production likeness; previews cover production likeness but assume the code reaching them is already sane. Hosted environments sell you one column that does both adequately and neither on your terms.
The complete self-hosted answer
So the pairing is the product. Run the inner loop in Lima: sterile --mount-none instances, agents launched through --sync, every change reviewed at the prompt before it touches your tree. Push the surviving branch and let your own cluster build it into an ephemeral preview with a seeded database and a per-branch URL, torn down on merge. The agent cannot hurt your laptop; the branch cannot reach production without proving itself somewhere shaped like production; and at no point did your dotfiles, your SSH keys, or your preview secrets leave machines you control.
Two operational notes make this real rather than aspirational. First, treat the Lima template as code: check the limactl template your team uses into the repo next to the Dockerfile, pin the agent CLIs it provisions, and the "works on my machine" conversation now includes "works in my agent's VM." Second, automate preview teardown ruthlessly — the failure mode of self-hosted previews is not cost per minute but forgotten branches consuming cluster capacity, so expire them on merge or close exactly as Railway does.
The broader point is about where the dev-environment center of gravity sits in the agent era. The hosted pitch says: agents are dangerous, so move development onto our managed, sandboxed, metered machines. Lima 2.1 says the sandbox can be a local VM with a review gate, and per-branch previews on owned infrastructure say production likeness does not require a landlord either.
Dev-prod parity was always about narrowing the gap between where code is written and where it runs. In 2026 the gap has a new occupant — an agent with shell access — and the narrowest, cheapest, most sovereign way to close it is a blast room on your laptop feeding previews on your cluster.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
