Repo of the day: clawk, a disposable VM to let coding agents run free

🔍 What clawk is: the third way between babysitting and reckless full-auto

clawk is a CLI written in Go (Apache-2.0, macOS 14+ on Apple silicon; Linux via firecracker, experimental) that builds a separate machine around the agent: the VM runs its own Linux kernel, and the host filesystem isn't hidden behind deny rules — it was simply never mounted. Inside the guest the agent is root: it installs packages, starts databases and dev servers, and runs untrusted builds at full speed.

The part I find most interesting is the declared stance on full-auto: inside sandboxes, runners launch in their "externally sandboxed" modes — Claude Code with `--dangerously-skip-permissions`, Codex with `--dangerously-bypass-approvals-and-sandbox`. On your real machine those flags would be reckless; here they are the point: containment comes from the VM boundary and the network allow-list, not from per-command confirmations. And if you want the prompts anyway, there's the `--safe` flag.

repo       clawkwork/clawk
language   Go 1.26+ · license Apache-2.0 · v0.2.0 (July 13, 2026)
platform   macOS 14+ Apple silicon · Linux (firecracker, experimental)
what       disposable Linux VMs for Claude Code, Codex or a shell
how        Virtualization.framework, rootfs from OCI images, no Docker
network    deny-by-default with a DNS-aware allow-list and denial log

⚙️ How it works: one command, one VM, the network filtered below the guest

The daily flow is stripped to the bone: `cd` into the repo and run `clawk` — the first boot builds a rootfs from any OCI image (it pulls and converts it to an ext4 disk by itself, no Docker daemon), and every boot after starts in seconds thanks to copy-on-write clones. The repo is live-mounted over virtio-fs, so the worktree the agent edits is the same one open in your editor.

The networking is the piece of engineering that convinced me to feature it: the VM's entire L3 layer — gateway, DHCP, DNS, NAT — is a userspace TCP/IP stack inside the daemon on the host. Every outbound connection and every DNS answer consults the allow-list there, where even root inside the guest can't touch it: common registries (npm, PyPI, GitHub, Anthropic) are pre-allowed, everything else is refused and lands in the denial log. SSH keys never enter the VM: the host's ssh-agent is forwarded, so `git push` works while signing stays outside.

cd ~/code/my-project
clawk                    # boot the VM + Claude Code already attached
clawk run codex          # same sandbox, another agent (or a shell)
clawk network denials    # what the agent tried to reach and got blocked
clawk forward add my-project 3000     # guest dev server on localhost:3000
clawk down               # stop: repo and conversations persist
clawk destroy && clawk   # VM wrecked? Recreate a clean one

🧰 Configuration and ticket mode: a sandbox per project, or per task

By default no config file is needed; when a project asks for more, you write a `clawk.mod` in go.mod-style syntax: CPU and memory, the OCI image to use as rootfs, extra hosts to allow, ports to forward, `on create` hooks and even instructions for the agent. The block is snapshotted when the sandbox is created, so a running environment never changes under your feet.

On top come the comforts that turn a VM into a workflow: `clawk snapshot` hibernates the guest (RAM saved to disk, dev servers included) and the next boot resumes exactly there; ticket mode creates, with `clawk work TICKET-123`, a sandbox with one git worktree per repo on dedicated branches, and `clawk pr` opens cross-linked PRs for whatever changed. Claude and Codex conversations are host-mounted, so they survive even a `destroy` and resume with `--resume`.

sandbox my-project (
    vm (
        cpu    4
        memory 8GiB
        image  golang:1.25      # any OCI image
    )
    network ( allow api.example.com )
    forwards ( 3000 )
    on create ( "go mod download" )
)

🏢 Why it matters, for developers and SMBs

For developers, clawk removes the real bottleneck of vibe coding: agent productivity collapses if every command waits for a confirmation, but the alternative — full autonomy on your work machine — exposes personal files, credentials and keys. Moving the boundary from the prompt to the hypervisor changes the nature of the risk: a wrong `rm -rf` costs a `clawk destroy && clawk`, not an afternoon of recovery. And compared to containers and devcontainers there's a structural difference: those share the host kernel and see the filesystem minus deny rules; here the kernel is a different one and the host was never mounted.

For an SMB adopting agents in its development processes, clawk's two logs are worth as much as the isolation: `clawk network denials` is the per-hostname list of what the agent tried to reach and got blocked — exactly the kind of visibility I wrote about when covering governance and shadow AI. And a `clawk.mod` versioned in the repo is an executable policy: same VM, same allow-list, same ports for everyone, developers and agents alike. The project itself, to its credit, is honest about the limits: whatever you mount or allow-list is exposed — github.com is pre-allowed and the forwarded ssh-agent can push — so code coming out of a sandbox should be reviewed like a stranger's PR.

⚠️ The limits to know before adopting it

The project is openly pre-1.0: v0.2.0 released July 13, breaking changes expected between releases and a handful of GitHub stars — I picked it for the quality of its documented design (ARCHITECTURE.md and DESIGN.md are among the best-written I've read lately), not for traction, which is still to be earned. The usual principle applies: a daily pick is a starting point for an evaluation, not a finished due diligence.

The technical perimeter matters too: you need an Apple silicon Mac on macOS 14+ (no Intel, no Windows; on Linux the firecracker provider is experimental), and the security stops where you configure it — secrets pushed into the VM are readable by the agent, and protection rests on Virtualization.framework isolation, with no extra defenses against hypervisor escapes.

• Pre-1.0 and very young: published in early July 2026, breaking changes declared between releases.
• Apple silicon only (macOS 14+) as the stable platform; Linux/firecracker experimental, no Windows.
• Whatever you mount is exposed: writable worktree and forwarded ssh-agent — reviewing the output is still on you.
• No protection for shared secrets: env vars and files pushed into the sandbox are readable (and sendable to allow-listed hosts).

✅ Where to start

The path I suggest: `brew install clawkwork/tap/clawk`, then run `clawk` inside a non-critical project to get familiar with the boot → work → `down` → `attach` cycle. Spend five minutes on `clawk network denials` after the first session: seeing what the agent tried to reach is instructive in itself. Then write the project's `clawk.mod` — image, allowed hosts, ports — and commit it, so the agent's environment travels with the repo.

In the bigger picture, clawk completes the containment ladder I've been writing about in recent weeks: command guardrails filter intentions, process sandboxes constrain a single program, and a disposable VM moves the whole workload onto a machine that isn't yours. Anthropic is investing in the same direction with Claude Code's native sandboxing: the shared message is that agent autonomy should be granted by architecture, not by trust.

More articles from the blog