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

Claude Code — Anthropic’s coding agent for the terminal — is a remarkably capable pair of hands. Point it at a repository, describe what you want, and it reads, edits, runs tests, and iterates. By default it asks for confirmation before anything risky. Started with claude --dangerously-skip-permissions — the bypass-permissions mode everyone ends up calling YOLO mode — it stops asking before each shell command and file write, and checks nothing at all. It gets dramatically faster as a result.

Don’t confuse that with Claude Code’s auto mode. There, a classifier model reviews each action before it runs: routine ones go through without a prompt, risky ones are blocked. That is a guard rail with judgement; YOLO mode has no guard rail at all. vibevm is built for YOLO mode — though a VM boundary doesn’t hurt under auto mode either.

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 YOLO 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.
• Prompt injection, which amplifies all of the above: instructions hidden in content the agent reads. 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.

The idea: a throwaway VM

vibevm is a disposable incus KVM virtual machine (Ubuntu 26.04 LTS) that exists to run Claude Code in YOLO mode. (incus manages containers and VMs; KVM is the Linux kernel’s built-in hypervisor.) 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 shared-folder mechanism for VMs.

One caveat up front: those shared directories are writable host data, and the VM does not protect them — more on that under the limits below.

Three layers of containment

The VM is the isolation boundary; the shared workspaces are the deliberate hole in it. 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 (YOLO 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         # restore guest state; shared host files are unchanged

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.
• 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 (a JDK version manager) with Temurin, Maven and Gradle; nvm and Node; headless Chrome plus Lighthouse for web and performance audits; and rootful Docker (the daemon runs as root). 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.

Shared directories are outside the boundary. They are writable host data: the agent can delete project files, read any secrets in them, and modify scripts or Git hooks that you later execute on the host. Restoring or deleting the VM does not undo changes to these directories. So:

• share only the workspaces the agent needs;
• keep credentials out of them;
• back them up separately;
• review changes before running project commands or Git hooks on the host.

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.