clawk: a disposable Linux VM for coding agents

The problem clawk solves: an agent that can actually run things

A coding agent becomes useful when it can install packages, execute the code it writes, start servers, and use the network. On a developer laptop that creates a choice the README states plainly: approve every command and babysit a prompt every few seconds, or pass --dangerously-skip-permissions and accept that one rm -rf or one leaked token is now in scope.

clawk is aimed at the second half of that trade-off. It gives the agent a disposable Linux VM instead of the host. The README's framing is that the boundary is not a rule in a prompt the agent could be argued out of, because it is a separate machine and the only openings are the mounts you created. Inside the sandbox the agent is root in the guest, so system package installs, edits to /etc, privileged ports and background services are all ordinary operations rather than policy exceptions.

The intended user is a developer working on macOS who runs autonomous agents against a real repository and wants the blast radius to be a VM disk rather than a home directory. That is a narrower audience than "anyone using an AI coding tool". If your agent only edits files and you review every diff, a process-level sandbox costs less.

How the clawk sandbox is built: Virtualization.framework, a tap device and an egress allow-list

The repository layout shows a Go CLI under cmd/ and internal/, plus a nested Go module in machine/ that go.mod describes as "the cross-platform VM library both providers boot through". On macOS the hypervisor is Apple's Virtualization.framework, linked into the binary through Code-Hex/vz, so there is no qemu and no Docker daemon on the host. On Linux the README says firecracker is the provider and that it is experimental.

Rootfs comes from an OCI image. The dependency list includes google/go-containerregistry, and the README states that any OCI image can serve as the rootfs and that the first boot builds a rootfs from your image while later boots take seconds. Host files reach the guest over 9p: the hugelgupf/p9 package is a direct dependency, which matches the claim that your code is mounted in rather than copied.

Networking is where the design gets specific. go.mod carries a replace directive pointing at github.com/clawkwork/gvisor-tap-vsock, described in a comment as a fork "which patches the TCP, UDP and ICMP forwarders to consult an egress allow-list before dialing". So the filter sits in the user-space network stack, not in the guest firewall. The README's demo shows a curl to an unknown host failing with connection refused, and notes that github.com is pre-allowed. The ssh-agent is forwarded, which is why git push works without a private key ever entering the VM.

Lifecycle is deliberately disposable. Code and conversations live on the host; only the VM disk is lost when you run clawk destroy. Idle VMs release memory and suspend to disk. The README also describes multi-repo tickets getting a git worktree per repo with coordinated PRs.

Installing clawk and running your first sandbox

The README requires macOS 14+ on Apple silicon. Linux is supported through firecracker but is described as experimental, with docs/linux-quickstart.md as the starting point. The macOS install is a Homebrew tap:

brew install clawkwork/tap/clawk

Building from source needs Go 1.26+ and goes through the Makefile rather than go run. The Makefile explains why: Apple's Virtualization.framework refuses to run an unsigned binary, and go run recompiles to a cache path that cannot be signed.

git clone https://github.com/clawkwork/clawk && cd clawk
make install

The install target runs go install ./cmd/clawk and, on Darwin, ad-hoc signs the result with the entitlements in clawk.entitlements. No Apple Developer ID is needed for local use. Either path avoids extra host tooling: no Docker, no qemu, no sudo.

With the binary on your PATH, the workflow is one command from inside a repository:

cd ~/src/my-project
clawk

The README says this boots a VM and attaches the agent; the demo GIF shows clawk booting a VM and attaching claude. From there the agent runs as root in the guest with your repo mounted. If the VM gets wrecked, the documented recovery is clawk destroy followed by clawk again, and --resume restores the conversation. To come back to a suspended sandbox later, the README shows clawk attach.

Where clawk stops: the allow-list, the platform gate and pre-1.0 churn

The README is unusually direct about the limit of its own network model. The allow-list blocks connections to unknown servers, not to servers you have allowed. github.com is pre-allowed and the forwarded ssh-agent can push, so the README's own instruction is to treat anything the agent can read as something it could publish. That is a real boundary, and it is a data-exfiltration boundary rather than a read boundary. If your repository contains a token the agent can see, an allowed destination plus a forwarded agent is enough to move it.

Platform is the second constraint. macOS 14+ on Apple silicon is the supported path. Linux exists but the README labels it experimental and points to a separate quickstart that covers "the gaps". The badge in the README says the same thing. If your team is on Intel Macs, Windows, or Linux workstations you expect to just work, this is the wrong tool today.

The project is pre-1.0 and says so. The README warns of breaking changes between releases and "the occasional rough edge", and frames the issue tracker as shaping 1.0. Three releases shipped in the weeks before the last push on 2026-08-13, which is consistent with that pace. Pinning a version and reading CHANGELOG.md before upgrading is the practical response.

Finally, the guest kernel override that enables Docker or Kind inside the sandbox is opt-in and hardware-gated. The README points to docs/images.md#guest-kernel-override for the exact requirements, which means nested container workflows are not the default experience.

clawk compared to devcontainers and process-level sandboxes

The nearest everyday alternative is a devcontainer: a Dockerfile or devcontainer.json that describes the environment, run by a container runtime on the host. The difference is the boundary. A container shares the host kernel and is constrained by namespaces, cgroups and seccomp, so a kernel-level escape or a misconfigured mount reaches the host. clawk boots a guest with its own kernel under a hypervisor, and the README's argument is that the host filesystem is not hidden behind deny rules because it was never mounted. The cost of that argument is a VM per project with its own boot and disk, and a hard requirement on Apple silicon.

A second comparison is the permission-prompt model itself, which is what clawk is replacing. Approving each command keeps the agent on the host with full access to your keychain and files, and depends on you reading every prompt carefully. clawk trades that attention for an allow-list you configure once. The trade is not free: an allow-list you set too broadly reproduces the original problem, and one you set too narrowly blocks the agent's work.

A third option is a remote cloud sandbox. clawk's distinguishing property there is locality: the VM runs on your machine, your repo is a 9p mount, and no code leaves the host unless the agent sends it to an allowed destination. That matters for private repositories and for latency when the agent is editing files continuously.

Licence, maintenance and upgrade cost

clawk is Apache-2.0, and the repository carries both LICENSE and NOTICE files. Apache-2.0 includes an explicit patent grant and requires that the NOTICE file be preserved in redistributions, which matters if you vendor or repackage the binary. That is a description of the licence text, not legal advice; check with your own counsel before redistributing.

One dependency detail is worth flagging for anyone auditing the supply chain. go.mod replaces github.com/containers/gvisor-tap-vsock with github.com/clawkwork/gvisor-tap-vsock, a fork that patches the TCP, UDP and ICMP forwarders to consult the egress allow-list. That fork is load-bearing for the security property: the network filtering is not upstream code. If you are evaluating the sandbox boundary, the fork is part of what you are evaluating.

The last push to the default branch was on 2026-08-13, the same day v0.4.0 was released. The README describes the project as pre-1.0 and moving fast, so upgrades should be treated as potentially breaking. Read CHANGELOG.md between versions, and expect to re-verify your image and allow-list configuration after a jump rather than assuming it carries over.

Editorial conclusion

Adopt clawk if you run autonomous coding agents on an Apple silicon Mac and want the hypervisor boundary rather than a process sandbox, and you accept pre-1.0 breakage. Do not adopt it if you need Linux as a first-class platform, if you cannot live with an egress allow-list that still permits the destinations you allowed, or if you need a stable interface across releases. Verify first that your machine meets the macOS 14+ Apple silicon requirement, that your image and toolchain work as an OCI rootfs, and that every host you need the agent to reach is one you are willing to add to the allow-list.

Frequently asked questions

Official sources

1. clawkwork/clawk on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases