clawk: a disposable Linux VM per coding agent

The babysitting problem clawk is aimed at

A coding agent that cannot install packages, run the code it wrote or start a server is not doing much. Once you grant those abilities on your own laptop, the README frames two bad options: approve every command and sit through a permission prompt every few seconds, or run with --dangerously-skip-permissions and accept that a leaked token or an rm -rf is one command away. clawk is presented as a third option. You cd into a repo, type clawk, and the agent works inside a disposable Linux VM with your code mounted in, root in the guest and no permission prompts. The intended user is someone already running an autonomous coding agent locally and uncomfortable with the blast radius, not someone looking for a hosted CI runner or a remote development box.

What actually enforces the boundary

The isolation is a hypervisor boundary, not a policy file. On macOS the hypervisor is Apple's Virtualization.framework, linked into the binary, so there is no separate qemu or Docker daemon on the host. The guest runs its own Linux kernel, which means the host filesystem is not hidden behind deny rules; it was never mounted. The only things that cross are the mounts you configured, and the README is explicit that the boundary is a separate machine rather than a rule in a prompt the agent could be argued out of. Inside, the agent has root and can edit /etc, install system packages, bind privileged ports or load a module. That is the design: a conventional Linux box where tools behave the way their documentation says, rather than a process sandbox where a syscall filter produces surprises. Network egress is allow-listed, and the README's own example shows a curl to an unknown host failing with connection refused after about two milliseconds while a git push succeeds because the host ssh-agent is forwarded.

Lifecycle: boot, destroy, attach, resume

The command surface is deliberately small. clawk boots a VM and attaches the agent; clawk destroy tears the VM down; running clawk again rebuilds from the same repo. The README's recovery story is exactly that sequence: clawk destroy && clawk gives a fresh VM with the same repo, and --resume restores the conversation. Your code and the agent's conversations live on the host, so only the disposable VM disk is lost. First boot builds a rootfs from your chosen OCI image; the README states that every boot after that takes seconds. Any OCI image can serve as the rootfs, which is how you get a full OS with the tools a specific project needs without writing a Dockerfile or a devcontainer config. Idle VMs are described as releasing memory and suspending to disk, so a forgotten sandbox costs almost nothing. Sandboxes are per project or per ticket, and multi-repo tickets get a git worktree per repo with coordinated pull requests.

Install and the platform constraint you cannot design around

Homebrew is the documented path: brew install clawkwork/tap/clawk. From source it is git clone https://github.com/clawkwork/clawk && cd clawk followed by make install, which needs Go 1.26 or newer. Release binaries ship with the in-guest agent prebuilt, so the Go toolchain is only required if you build from source. Either way the README says there is no extra host tooling: no Docker, no qemu, no sudo. First run probes for anything missing and offers to fix it. The constraint is the host. macOS 14 or newer on Apple silicon is the supported configuration. Linux exists via firecracker and is labelled experimental, with docs/linux-quickstart.md covering setup, workflow and gaps. This is not a packaging detail you can work around with a container. Virtualization.framework is Apple's, and the supported path is tied to it. If your team is on Linux workstations or Intel Macs, the README's own framing puts you in the experimental branch or out of scope entirely.

Where the allow-list does not save you

The README volunteers the limitation rather than burying it. The allow-list blocks connections to unknown servers, not to servers you have already allowed. github.com is pre-allowed, and the forwarded ssh-agent can push, so anything the agent can read is something it could publish. The documented example is unambiguous: cat ~/.ssh/id_rsa fails because keys never entered the VM, yet git push works. That is a deliberate trade, and it means the sandbox protects your host and your keychain, not your repository contents. There is a second boundary worth naming. Running Docker or Kind inside the sandbox requires a KVM-enabled guest kernel on supported hardware, is opt-in, and is hardware-gated; the README points at docs/images.md#guest-kernel-override for the exact requirements. So the container-inside-the-VM workflow, which the README calls the sharpest example of needing a real machine, is the least portable part of the product. A third caveat is stated plainly at the top: pre-1.0 and moving fast, with breaking changes between releases expected.

How this differs from a process sandbox

The obvious alternative is a process-level sandbox such as macOS Seatbelt or a Linux seccomp profile, which wraps the agent in deny rules on the machine you are already using. The difference is where the policy lives. A process sandbox has to enumerate what the agent may touch, and every gap in that enumeration is a gap in the boundary. clawk inverts it: the host filesystem is absent from the guest rather than denied to it, so there is no rule to get wrong. The cost is a VM to build and boot, a rootfs derived from an OCI image, and a host platform that can run the hypervisor. The benefit shows up in workloads a syscall filter fights you on: installing native dependencies, running background services like databases and queues, executing untrusted builds at full speed, and using system-level Linux tooling that expects a real machine. If your agent only edits files and runs a test suite, that trade is harder to justify.

Maintenance cost and the licence

Three releases are listed in the supplied material: v0.2.0 on 2026-07-13, v0.3.0 on 2026-08-05 and v0.4.0 on 2026-08-13. That cadence, roughly three weeks between v0.2.0 and v0.3.0 and eight days between v0.3.0 and v0.4.0, is the maintenance signal that matters most here, because the README warns of breaking changes between releases. Budget for reading release notes before upgrading rather than pinning and forgetting. There is a CI workflow referenced from the README badge, and the repository is not archived. On licensing, clawk is Apache-2.0, which permits commercial and internal use and includes an explicit patent grant; the usual obligations around attribution and notice files apply. That is a description of the licence text, not legal advice, and if you plan to redistribute a modified clawk inside a product, have counsel read the NOTICE and LICENSE files rather than this paragraph.

Who should take the dependency

The fit is narrow and specific. You are on an Apple silicon Mac with macOS 14 or newer, you already run Claude Code, Codex, pi or a shell as an agent, and you want it to install packages, start servers and run untrusted builds without a prompt every few seconds. In that situation clawk removes the approval loop without handing the agent your keychain, and the destroy-and-recreate cycle means a wrecked VM costs you a rebuild rather than a restore. The misfit is equally specific. Linux users are on an experimental path documented in docs/linux-quickstart.md. Anyone who needs the agent to publish to a repository should understand that github.com is pre-allowed and the forwarded ssh-agent can push. Anyone whose workflow depends on Docker or Kind inside the sandbox should read docs/images.md#guest-kernel-override before assuming it works on their hardware. And anyone who wants a stable interface should wait: the README says breaking changes between releases are expected, and the version numbers agree.

Editorial conclusion

Adopt clawk if you run Claude Code, Codex, pi or a plain shell on an Apple silicon Mac running macOS 14 or newer, and you want the agent to install packages, start servers and run untrusted builds without approving every command. Do not adopt it on Linux expecting the same experience: the README calls that path experimental and points at docs/linux-quickstart.md for the gaps. Before you commit, verify the guest kernel requirements in docs/images.md if you want Docker or Kind inside the sandbox, confirm your OCI image builds a rootfs on first boot, and read the security model section that admits github.com is pre-allowed and a forwarded ssh-agent can push. Pre-1.0 software with breaking changes between releases is a real cost here, not a disclaimer.

Official sources

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