vibevm: running Claude Code in auto mode without burning down your host

Claude Code is a remarkably capable pair of hands. Point it at a repository, describe what you want, and it reads, edits, runs tests, and iterates. In auto mode (claude --dangerously-skip-permissions, which everyone ends up calling “YOLO mode”) it stops asking permission before each shell command and file write — and gets dramatically faster as a result.

It also gets dramatically more dangerous. We wanted the speed without betting the host on every run, so we built a sandbox for it and open-sourced the result: vibevm.

What auto mode actually risks

Take away the confirmation prompt and the failure modes are concrete:

Destructive commands — an rm -rf in the wrong directory, a bad migration, a force-push.
Credential theft — reading ~/.ssh, cloud tokens, .env files. This is sharply amplified by prompt injection: a malicious README, a web page, or an npm postinstall hook can all carry instructions the agent then dutifully follows.
Uncontrolled egress — fetching payloads, or quietly shipping your data somewhere.
Host persistence — leaving something behind that runs after the session ends.

You can trust the agent and hope. Or you can give it a room it can’t get out of.

The idea: a throwaway VM

vibevm is a disposable incus KVM virtual machine (Ubuntu 26.04 LTS) that exists to run Claude Code in auto mode. You keep editing your projects on the host with your usual tools; Claude works on the same files inside the VM, shared live over virtiofs. A destructive command, a leaked secret, or a prompt-injection payload can’t reach past a guest you can throw away.

Three layers of containment

Layer	How
Blast radius	A full KVM VM with its own kernel, disposable. Broke it? Restore the `clean` snapshot or delete the VM.
Egress allowlist	A domain-allowlisting proxy (`tinyproxy`) inside the VM; `nftables` default-drops everything else, so all web traffic is forced through it.
Least privilege	Claude runs as the unprivileged `vibe` user — no sudo. IPv6 is off so the IPv4 allowlist is total, and only a scoped API key is injected, at launch.

The boundary that ultimately matters is the VM itself — its own kernel, disposable, snapshotted. The other two layers shrink what a single bad run can do before you notice and reset.

Why a real VM — and why just shell scripts

Two choices we made on purpose.

A real VM, not a container. The agent runs with the safety prompt off, so the boundary has to hold against a fully-capable process that might be acting on someone else’s instructions. Containers share the host kernel; one kernel bug reaches the host. A KVM VM runs its own kernel behind a hardware-virtualization boundary — a much higher bar to clear.

A handful of shell scripts, not a stack of images. vibevm is plain incus and plain Ubuntu, provisioned with apt, curl, and nft you can read top to bottom. There’s no custom image to build, publish, and trust, and no orchestration layer. For a security tool, “you can see exactly what it does” is a feature, not a gap.

Living in it

After a one-time ./install.sh — it sets up the incus daemon, drops vibe on your PATH, and installs shell completions — everything is one command:

vibe create          # build and provision the VM
vibe                 # start Claude (auto mode) in ~/workspace
vibe .               # ... in the project for your current host directory
vibe shell           # a login shell in the VM
vibe firewall off    # open egress when you knowingly need it
vibe restore         # roll back to the clean snapshot

Two details we’re fond of. Git pushes happen on the host, never in the VM: the guest holds no git credentials and SSH is blocked, so the agent commits inside the VM (with your host identity) and — because the repo is shared — you push from the host with your real keys. And state survives a rebuild: vibe persist backs the VM’s ~/.claude (history, sessions, file-based memory, login) onto the host, so you can delete and rebuild the VM without losing context.

Batteries included — with an opinion

Out of the box the toolchain leans hard toward Java and frontend/web development: SDKMAN with Temurin, Maven and Gradle; nvm and Node; headless Chrome plus Lighthouse for web and performance audits; and rootful Docker. That’s our stack — it’s almost certainly not exactly yours, so every bit of it is configurable via vibevm.conf (versions, extra apt packages) or a single provisioning script. The defaults are an opinion, not a cage.

Open source — and honest about the limits

vibevm is Apache-2.0 and lives at github.com/tgbyte/vibevm. Issues and pull requests are welcome — security reviews and hardening most of all.

Because it is a security tool, we’ll be blunt: the isolation is best-effort and has not had a formal third-party audit. Treat the guest as untrusted, keep real host credentials out of it, and decide for yourself whether the guarantees match your risk tolerance. Rootful Docker is an explicit trade-off, too — the docker group is root-equivalent in the VM and container traffic side-steps the allowlist — which is precisely why the VM, not the allowlist, is the real boundary.

Try it

git clone https://github.com/tgbyte/vibevm.git && cd vibevm
./install.sh
vibe create
vibe

You’ll need a Linux host with incus and KVM virtualization; the script takes care of the rest. Let the agent go fast — just not on your laptop.