macOS · Apple Virtualization.framework · MIT

Run your coding agent on your Mac —
without the anxiety.

Claude Code, Cursor, Cline, and friends pip install whatever a README names, execute model output, and act on web pages that can carry prompt injection. vmette gives that work somewhere safe to happen: a real, hardware-isolated Linux VM that boots in ~1 second, sees only what you share in, and disappears when it's done.

Install View on GitHub 
# macOS only — installs to ~/.local/share/vmette
curl -fsSL https://github.com/chamuka-inc/vmette/releases/latest/download/install.sh | bash
vmette booting a Linux guest, propagating its exit code to the host, and enforcing default-deny networking until --net is passed

Why on-device

Cloud sandboxes are just as well-isolated — the difference is keeping that isolation on-device: no round-trip, no meter, nothing leaves the laptop.

Cloud sandboxContainer (Docker)vmette
Isolation boundarymicroVM / gVisor (varies)shared host kernelhardware VM, its own kernel
Where it runssomeone else's cloudyour machineyour Mac
Code & secretsleave the devicestay localstay local
Network egresson by defaulton by defaultoff until you pass --net
Costusage-meteredfreefree, on-device
Boot timesub-second + network round-trip~sub-second~1 second, local

Three ways in

One VM primitive, three surfaces: hand it to an agent over MCP, drive a full graphical desktop for computer use, or run a one-off command from the CLI.

Agent sandbox (MCP)

vmette-mcp hands any MCP-aware agent host a sandboxed machine as tools: execute, fetch_url, workspace_*. Work the agent runs through these tools is confined to the VM. 

claude mcp add vmette --scope user \
  -- vmette-mcp --allow-network
docs/MCP.md →

Computer use (desktop)

A persistent graphical Linux desktop inside a microVM — screenshot, click, type — driven by an in-guest agent over vsock. Watch and take over any session live over VNC. 

vmetted &
SID=$(vmette desktop start)
vmette desktop click "$SID" 640 400
open "$(vmette desktop view "$SID")"
docs/DESKTOP.md →

One-off command (CLI)

Pull an OCI image, tarball, squashfs image, or local directory and run a command in it. Exit code propagates to the host; network and shares are opt-in. 

vmette --rootfs python:3.12-alpine \
  --exec 'python3 -c "print(2**32)"'
docs/CLI.md →

For teams and products

Past the individual dev workflow, the same primitive is a building block wherever untrusted code needs to run close to the data, without a per-run cloud bill or a compliance review.

Agent fleets, controlled cost

Engineering orgs running many AI coding agents in parallel hit cloud sandbox meters fast. On-device microVMs are free to spin up, so cost scales with hardware you already own, not per-second billing.

Untrusted code in your product

SaaS products that let users submit code, scripts, or plugins need isolation per request. Embed vmette as a Rust crate, C library, or daemon and get a hardware-isolated run without standing up cloud sandbox infrastructure.

Regulated environments

Finance, healthcare, and other regulated teams often can't send proprietary code or customer data to a third-party cloud sandbox. Because the VM is local and network-off by default, code and secrets never leave the machine unless you explicitly allow it.

Hermetic CI, locally

Reproduce a CI job's isolation on a laptop — same default-deny network, same disposable rootfs — for debugging flaky builds or running client/consultant work without polluting the host.

Automate legacy, API-less software

Plenty of business-critical software — old ERPs, lab instrument consoles, vendor tools with no scriptable interface — only exposes a GUI. Computer-use agents can screenshot, click, and type against it inside a disposable desktop VM, so automation doesn't need an API that was never built.

Safer RPA on unmaintained systems

Process automation against unpatched legacy desktop apps carries real risk if a scripted action misfires. Running it in a network-off microVM that boots fresh each session contains the blast radius and removes state drift between runs, instead of scripting against a shared machine.

How it works

1

vmette builds a VZVirtualMachineConfiguration (kernel, initramfs, virtio devices, vsock).

2

The kernel cmdline carries only a boot flag; everything per-invocation — exec, env, rootfs mode, shares, scratch device, net — travels in a typed envelope the guest's /init sources in pure shell before it chroots into the rootfs and runs the command.

3

The guest writes its exit code to a file, syncs, and powers off. The host reads the file and exits with that code.

4

An immutable squashfs rootfs attaches read-only as virtio-blk with a tmpfs overlay, so the base stays content-addressable and shareable across sessions.

Embed it

The same VM primitive is also a Rust crate, a C-ABI dynamic library, and a long-lived daemon, for building your own agent host or sandbox tooling on top.

Rust

vmette::run(&cfg) blocks until guest poweroff, returns the guest's exit code.

C ABI

Opaque handles, cbindgen-generated vmette.h, paired *_new/*_free.

Daemon

vmetted speaks line-delimited JSON over a UNIX socket; amortizes per-run cost.

Docs

MCP.mdvmette-mcp tool reference + client configs DESKTOP.mdDesktop sessions, protocol, image build CLI.mdFull flag reference API.mdRust + C library API DAEMON.mdvmetted protocol spec HACKING.mdBuild, test, debug, repo layout