Clawk: Disposable Linux VMs for AI Coding Agents

Clawk is a local environment manager that provides AI coding agents with disposable Linux virtual machines (VMs) instead of direct access to a user's host machine. By isolating the agent in a separate VM with its own kernel and a restricted network allow-list, Clawk enables developers to run agents with full autonomy—using flags like --dangerously-skip-permissions—without risking the host's filesystem, keychain, or network security.

Why Virtual Machines for AI Agents

Clawk uses a full VM rather than a process-level sandbox or container to ensure a stronger security boundary and a more conventional Linux environment.

• Kernel Isolation: The guest runs its own Linux kernel, meaning the host filesystem is never mounted and cannot be accessed via kernel exploits or misconfigured deny rules.
• Root Access in Guest: Agents can install system packages, edit /etc, and bind privileged ports without affecting the host machine.
• Conventional Tooling: Because it is a real Linux box, tools behave as documented without the syscall-filter surprises often found in restricted process sandboxes.
• Disposable Lifecycle: A compromised or wrecked VM can be instantly replaced using clawk destroy && clawk, while the project repository and agent conversation history remain safe on the host.
• Nested Virtualization: With a KVM-enabled guest kernel on supported hardware, developers can run Docker or Kubernetes (e.g., Kind) inside the sandbox.

Core Features and Workflow

Clawk is designed for a "one command" setup, removing the need for Dockerfiles or complex configuration files for basic use cases.

Quickstart and Lifecycle

Developers can boot a sandbox for the current directory by running clawk. Common lifecycle commands include:

• clawk run shell: Drops the user into a shell within the active sandbox.
• clawk down: Stops the VM while persisting the repository and agent state.
• clawk attach: Re-boots and re-attaches the AI agent (e.g., Claude Code) to the session.
• clawk destroy: Completely removes the VM disk.
• clawk snapshot: Hibernates the VM, saving both RAM and disk state to allow for near-instant resumption of background processes.

Networking and Security

Clawk implements a "deny-by-default" outbound network policy enforced in userspace below the guest VM, meaning even a root user inside the guest cannot bypass the filter.

• Allow-listing: Common registries (npm, PyPI, GitHub, Anthropic) are pre-allowed. Users can add specific domains via clawk network allow.
• Traffic Logging: clawk network denials provides a log of every hostname the agent attempted to reach that was blocked by the filter.
• Secret Management: To avoid placing private keys inside the VM, Clawk forwards the host's ssh-agent, allowing the agent to perform git push operations without the keys ever leaving the host machine.

Configuration via clawk.mod

For complex projects, a clawk.mod file allows for declarative environment definitions, including CPU/memory limits, specific OCI images for the rootfs, environment variables, and custom agent instructions.

Technical Architecture

Clawk avoids reliance on a host Docker daemon by pulling OCI images and flattening them directly into ext4 disks. On macOS, it leverages Apple's Virtualization.framework; on Linux, it uses Firecracker (currently experimental).

The data flow is structured as follows: User CLI $\rightarrow$ Per-sandbox Daemon $\rightarrow$ gvproxy (Userspace TCP/IP stack for filtering) $\rightarrow$ vsock bridge (Control path to guest) $\rightarrow$ VM (Guest Kernel + OCI rootfs).

Comparison to Other Sandboxing Methods

Method	Host Security	Tooling Compatibility	Setup Overhead
Containers	Shared kernel; risk of escape via syscalls	High	Requires Docker/Podman
Process Sandboxes	Policy-based; risk of misconfiguration	Medium	Low
Clawk (VMs)	Hypervisor boundary; separate kernel	Very High	Low (No Docker daemon needed)
Cloud Sandboxes	High	High	High (Latency, billing, data egress)

Community Perspectives and Alternatives

Discussion around Clawk highlights a growing trend of "agent-specific" sandboxing. While some users suggest that simple separate OS users or tools like Firejail and bubblewrap provide sufficient isolation, others argue that the hypervisor boundary is necessary for agents that need to install system-level dependencies or run background services.

Other mentioned alternatives include:

• yoloAI: A similar FOSS project supporting multiple sandbox backends (gVisor, Kata, Firecracker).
• katsuobushi: A Nix-flake based sandbox using microvm.nix.
• flar: A lightweight namespace-based wrapper for agents.
• Agentjail: Uses OS-native sandboxes (sbpl for macOS) with Open Policy Agent (OPA) guardrails.