GitHub - clawkwork/clawk: Disposable, network-restricted Linux VMs for AI coding agents

Give a coding agent its own disposable Linux machine, not yours.

Install · Quickstart · Why a VM? · How it works · Compared to · FAQ · Docs

A coding agent is only useful when you let it actually do things: install packages, run the code it writes, start servers, use the network. On your own machine that leaves two bad options. You approve every command (and babysit a prompt every few seconds), or you run --dangerously-skip-permissions and hope nothing important is one rm -rf or one leaked token away. clawk is a third option. cd into a repo, type clawk, and Claude Code (or Codex, or a shell) is working inside a disposable Linux VM (your code mounted in, root in the guest, no permission prompts) while your files, your keychain, and the rest of your machine stay out of reach. The agent gets its own machine instead of yours.

One command to a working agent; an attempt to send data to an unknown server, blocked by the network allow-list; clawk attach resumes the session later.

The boundary isn't a rule in a prompt the agent could be talked out of. It's a separate machine, and the only openings are the ones you mounted. From a shell inside a sandbox: $ curl https://tracker.evil.example # not on the allow-list: blocked curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa # your keys never entered the VM cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push # ...yet this works: ssh-agent is forwarded Enumerating objects: 5, done. To be honest about the limits, the allow-list blocks connections to unknown servers, not to ones you've allowed: github.com is pre-allowed and the forwarded ssh-agent can push, so treat anything the agent can read as something it could publish. The security model spells this out. And if the agent wrecks the VM, run clawk destroy && clawk: a fresh VM, same repo, and --resume restores the conversation. ImportantPre-1.0 and moving fast.

Expect breaking changes between releases and the occasional rough edge; things can and will break. Please file issues; that feedback is shaping 1.0.

Highlights

Let the agent do anything. It runs in a disposable VM with a restricted network, so rm -rf, package installs, and untrusted code can't reach your host, your files, or anything you didn't explicitly share. Working in one command. cd into a repo and run clawk. No Dockerfile, devcontainer, or setup file. First boot builds a rootfs from your image; every boot after takes seconds. Break it without losing anything. Destroy and recreate freely; your code and the agent's conversations live on the host. Only the disposable VM disk is lost. A real Linux box, your toolchain. Any OCI image is the rootfs: a full OS with exactly the tools your project needs. No Docker daemon required. Secrets stay on your machine. Outbound traffic is allow-listed and your ssh-agent is forwarded, so git push works without keys entering the VM. A sandbox per project or ticket. Run several at once; multi-repo tickets get a git worktree per repo with coordinated PRs. Idle VMs automatically release memory and suspend to disk, so a forgotten sandbox costs (almost) nothing.

Why a VM? clawk is a general-purpose local environment for autonomous coding agents. The VM is the point: it's a whole machine the agent can own, not a process wrapped in policy on the one you're using.

A separate kernel. The guest runs its own Linux kernel, so the host filesystem isn't hidden behind deny rules; it was never mounted. A conventional Linux environment. Standard kernel, standard userland, /dev/kvm-shaped expectations, so tools behave the way their docs say, without a syscall-filter surprise. Root in the guest. Install system packages, edit /etc, load a module, bind a privileged port. It's the agent's box to reconfigure. A disposable lifecycle. Cheap to break and quick to recreate; a wrecked VM is one clawk destroy && clawk away, with your repo and conversations untouched on the host. Stronger separation from the host. Isolation rests on the hypervisor boundary rather than on getting a process-sandbox policy exactly right.

That combination runs workloads a restricted process sandbox tends to fight you on:

installing packages and native dependencies; running background services (databases, queues, dev servers); executing untrusted builds and tests at full speed; using system-level Linux tooling that expects a real machine; and, with a KVM-enabled guest kernel on supported hardware, container and Kubernetes dev workflows such as Docker or Kind running inside the sandbox. This is opt-in and hardware-gated; see Images for the exact requirements.

None of this is the product; clawk is for local agent work in general. Docker and Kubernetes are just the sharpest example of "needs a real machine, not a sandboxed process." Install Requires macOS 14+ on Apple silicon. (Linux is supported via firecracker and currently experimental; see VM providers for the gaps. This README is macOS-first.) brew install clawkwork/tap/clawk From source (contributors, or if you don't use Homebrew), needs Go 1.26+: git clone https://github.com/clawkwork/clawk && cd clawk make install Either way there's no extra host tooling: no Docker, no qemu, no sudo. The hypervisor is Apple's Virtualization.framework, linked into the binary. First run probes for anything missing and offers to fix it. Uninstall: clawk destroy your sandboxes, rm -rf ~/.clawk, then remove the binary with brew uninstall clawk (or delete it from $GOBIN for a source install). Nothing else was installed: there are no launchd jobs; the per-sandbox daemons are ordinary processes that exit with their VMs. Quickstart The everyday case, a sandbox for the directory you're in: cd ~/code/my-project clawk # boot a sandbox for this dir + attach claude clawk run shell # drop into a shell in the same sandbox clawk run codex # or another agent: codex, opencode, shell clawk down # stop the VM (repo + agent state persist) clawk attach #

come back later — boots if stopped, reattaches claude clawk destroy # remove the VM (conversation history is kept) Common options: clawk run claude -- --resume # pass args through to the agent clawk forward add my-project 3000 # expose a guest dev server on localhost:3000 clawk network allow my-project api.example.com Working on a ticket that spans several repositories? One command creates a sandbox with a git worktree per repo on a fresh branch, and clawk pr later opens cross-linked PRs for whatever changed: cd ~/code/my-workspace # contains a clawk.mod listing the repos clawk work INFRA-123 # one sandbox, a worktree per repo, claude attached clawk pr INFRA-123 # push branches + open one PR per repo The full ticket lifecycle (status, follow-up branches after merges, rebases) is in docs/ticket-mode.md.

Tip: using Claude Code? Run claude setup-token then clawk auth set-token once, and every sandbox comes up already signed in, with no /login and no login conflicts between parallel sandboxes. See docs/claude-auth.md.

What survives what One rule governs persistence: the VM is disposable; everything you'd miss lives on the host.

clawk down clawk destroy

Your repo (mounted worktree; commits, branches) ✅ ✅

Agent state (Claude/Codex conversations, memory) ✅ ✅

The VM disk (apt installs, caches, $HOME) ❌ (rebuilt fresh at every boot*) ❌ (that's the point)

* Two exceptions: resuming a clawk snapshot restores the disk and memory exactly as suspended, and the Linux/firecracker provider keeps its disk until destroy. Tools every boot needs belong in the image (vm ( image … )); per-boot setup belongs in on up hooks.

Agent state is host-mounted per sandbox: the guest's ~/.claude/projects/ and ~/.claude/memory/ (and codex's ~/.codex/) live under ~/.clawk/namespaces/default/state/<name>/ on the host, so a recreated sandbox picks up its old conversations with --resume. Full autonomy by default (and the --safe opt-out) Runners launch in their "externally sandboxed" modes: claude gets --dangerously-skip-permissions, codex gets --dangerously-bypass-approvals-and-sandbox. On your own machine those flags would be reckless; here they are the point: the VM boundary and the network allow-list provide the containment, so the agent works at full speed without per-action prompts. The agent can only affect what you mounted and allow-listed, nothing more (see SECURITY.md). Prefer the confirmation prompts anyway? Add --safe to any attach (clawk --safe, clawk run claude --safe) and the runner starts without its bypass flags for that session. Networking Outbound traffic is denied by default; each sandbox has its own allow-list. DNS resolves everything; TCP, UDP (including QUIC), and ICMP echo to unlisted hosts are refused. Common registries (npm, PyPI, crates.io, GitHub, Anthropic, …) are pre-allowed, and the filter is DNS-aware, so allowing example.com keeps working as its IPs rotate. clawk network allow my-project api.stripe.com '*.internal.mycorp.com' 10.0.0.5 clawk network denials my-project # what the agent tried that got blocked clawk forward add my-project 3000 # localhost:3000 → the guest's dev server Denials are recorded by the hostname the guest resolved, so clawk network denials reads as a log of what the agent tried to reach. Reusable named policies (including subscribing to external blocklists like oisd) and the use chain that layers them are in docs/networking.md. Configuration: clawk.mod No config file is required; defaults are sensible.

When a project needs more, a clawk.mod file describes it, in a go.mod-style syntax: sandbox my-project ( vm ( cpu 4 memory 8GiB image golang:1.25 # any OCI image is the rootfs ) network ( allow api.example.com ) forwards ( 3000 ) env ( DATABASE_URL ) # names only; values come from your shell on create ( "go mod download" ) agent ( instructions "Ask before running destructive commands." ) )

The block is a template: snapshotted when the sandbox is created, so a running sandbox never changes unexpectedly. The full reference (shares, secret files, skills, agent memory seeding, multi-repo workspace roots) is in docs/configuration.md; images and custom guest kernels (including the KVM-enabled kernel used for nested virtualization) are in docs/images.md. Lifecycle clawk list # all sandboxes clawk status [<name>] # state, forwards, blocked hosts; --json for scripts clawk up / down # boot / stop clawk pause / resume # suspend / resume the running VM in memory clawk snapshot # save to disk: RAM freed, guest intact; resume restores it clawk destroy # remove the VM; host-side state persists clawk snapshot is hibernation for sandboxes: the guest's memory is saved beside its disk and the next boot restores the guest exactly where it was. Background processes and dev servers continue as if nothing happened, and clawk attach puts you back in front of the agent. The full command surface, runner dispatch, and the idle-management machinery (ballooning, admission control, auto-stop) are in docs/commands.md. How it works you ──▶ clawk CLI ──▶ per-sandbox daemon (detached; owns the VM) ├─ gvproxy: in-process userspace TCP/IP stack — │ the DNS-aware outbound filter the guest can't reconfigure ├─ vsock bridge to the in-guest pty-agent (no sshd) ├─ ssh-agent proxy, macOS (signing stays on