Clawk: Disposable Linux VMs for Coding Agents Without Cloud Bills

The Grok CLI uploading user home directories to xAI's servers this weekend was a reminder of what happens when you give an AI agent unrestricted access to your machine. Most of us have been there - running --dangerously-skip-permissions because clicking "approve" 47 times per session is unbearable, then hoping nothing goes wrong.

Clawk, a new open-source project that hit HN's front page today, offers a different approach: give the agent its own disposable Linux VM, not yours.

What Clawk Does#

Clawk spins up an isolated Linux virtual machine on your local machine using Apple's Virtualization.framework (macOS) or Firecracker (Linux, experimental). Your coding agent - Claude Code, Codex, or any other - runs inside the VM with full shell access. When the session ends, you can destroy the VM completely or snapshot it for later.

The key differentiator from just running Docker: Clawk includes a DNS-aware network firewall that blocks outbound connections by default. Common registries (GitHub, npm, PyPI, crates.io) are pre-allowed, but everything else requires explicit approval:

clawk network allow my-project api.example.com

This means an agent that gets prompt-injected or runs malicious code from a compromised npm package cannot phone home to arbitrary servers - the connection just fails at the userspace network layer.

Why Not Just Docker?#

The HN discussion covered this thoroughly. The short answer: containers share a kernel with your host.

As one commenter put it: "Virtualization presents an infinitely smaller attack surface." A container escape gives an attacker access to your host system. A VM escape requires a hypervisor vulnerability, which is a much harder target.

The practical differences go beyond security. Clawk uses copy-on-write disk clones from OCI images, so spinning up a fresh VM costs only the delta of what the guest writes. Multiple sandboxes can run simultaneously. Idle VMs automatically suspend to minimize resource usage.

For teams running Docker-in-Docker or Kubernetes inside agent sandboxes - common for infrastructure agents - a VM just works. No nested virtualization hacks.

How It Works#

The architecture combines several components:

Hypervisor: Apple's Virtualization.framework on macOS, Firecracker on Linux. Both provide hardware-level isolation without requiring root (on macOS).

Network Stack: An in-process userspace TCP/IP stack (gvproxy) terminates the guest's connections and re-dials them as host sockets. The firewall is an allow-list check right before the dial - no iptables, no nftables, no root required on macOS.

Access: Single vsock agent connection. No SSH daemon running inside the VM, no cloud-init bootstrap complexity.

Storage: OCI images as rootfs, so you can use any standard container image as your base environment.

The workflow is simple:

cd my-project
clawk              # Boot VM, attach Claude Code
clawk run shell    # Access shell in same sandbox
clawk down         # Stop VM (state persists)
clawk attach       # Resume later
clawk destroy      # Remove VM entirely

Port forwarding lets you access services running inside the VM:

clawk forward add my-project 3000

What HN Is Saying#

The discussion surfaced several interesting points:

Security skepticism is healthy. One commenter asked what happens when "the agent figures out it's in a container and finds an exploit." A valid concern - but as the author noted, even sophisticated models like Fable couldn't escape during stress testing. VMs present a much smaller attack surface than containers.

Alternatives exist. Several people mentioned similar projects: YoloAI, Fly.io Sprites, virtdev, systemd-nspawn via mkosi. The space is clearly seeing demand.

Corporate environments are different. Some developers cannot run arbitrary VMs but can run Docker. Clawk is designed for developers who have that flexibility - it's a local tool, not a managed service.

The "separate user account" approach is insufficient. Several commenters suggested just running agents as a different Unix user. The responses were clear: shared kernel, world-readable files, unrestricted network access, and privilege escalation paths all make this inadequate for hostile code execution.

The Supply Chain Angle#

Beyond direct agent misbehavior, Clawk addresses a subtler threat: supply chain attacks through npm, pip, and cargo packages.

As one commenter noted: "I'm not worried about the agent at all. The VM is there to prevent it from clobbering files on my real system. I'm worried about supply chain attacks on npm, pip, cargo and everything else."

When your agent runs npm install some-package, that package runs arbitrary code during installation. Inside a VM with restricted network access, a malicious package cannot exfiltrate data to a random server - the connection fails.

Current Limitations#

Clawk requires macOS 14+ on Apple Silicon for the Virtualization.framework path. Linux support via Firecracker exists but is marked experimental and requires more setup.

The project is pre-1.0, so breaking changes are expected. The README is honest about this.

Network filtering happens at the userspace level, not via traditional firewall rules. This is actually a feature (no root required) but means you cannot use standard Linux firewall tooling to inspect or modify rules.

Practical Recommendation#

If you're running coding agents with full shell access - especially unattended or on untrusted codebases - sandboxing is not optional. The question is how much friction you're willing to accept.

Clawk's approach is compelling: local VM isolation without cloud bills, network firewall out of the box, works with any agent harness, and open source. The tradeoff is it's macOS-first and early-stage.

For cloud-based alternatives with managed infrastructure, see our sandbox comparison covering E2B, Daytona, Modal, Cloudflare Sandbox, and Vercel Sandbox.

For local development where you want maximum control and zero egress, Clawk is worth trying.

Sources#

• Clawk GitHub Repository
• Hacker News Discussion
• Apple Virtualization Framework
• Firecracker MicroVMs
• gvproxy - gVisor TAP/vsock networking