Clawk - Disposable Linux VMs for AI coding agents
Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop
Clawk provides a secure, disposable Linux VM environment specifically designed for AI coding agents like Claude Code and Codex. Instead of running potentially risky commands on your local machine, Clawk spins up an isolated virtual machine where agents can install packages, execute code, and manage servers with full autonomy. It features a restricted network allow-list to prevent unauthorized data exfiltration while forwarding your SSH agent for seamless Git operations. With a single command, developers can launch a sandboxed workspace that protects their host system from accidental damage or security breaches, offering a robust solution for autonomous development workflows.
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.
- docheinestages
I think the most secure setup, though not so convenient for the average user, is a separate machine with QEMU/KVM. The machine should be isolated adequately, such that even if compromised, it shouldn't be able to cause damage or gain access to other machines. Additionally, a proxy server on your machine or elsewhere could hide sensitive credentials. A helper binary on your computer would then control spawning new disposable VMs with premade images and your SSH key. The images can be lightweight or the desktop version with a remote VNC.
- SwellJoe
I was using VMs for agents, but wanted something lighter and faster, so I made flar, which bubblewraps the agent, its config/history and the project directory. The agent runs in your usual environment but has no access to anything other than what it's been explicitly granted, short-circuiting prompt injections (or intentional secret exfiltration on the part of the agent or model) as well as any supply chain exploits the agent might accidentally introduce.
https://github.com/swelljoe/flar
It starts instantly, as it's a namespace, rather than a full VM or container that has to be downloaded/built/updated on start.
It defaults to dangerously skip permissions mode, but is much safer than the very porous sandbox the agents provide, and the agent can't reach outside of it even if told to, by the user or a prompt injection.
- einhard
I am certainly no expert in this space so it is quite possible I'm missing something critical, but what seems to work for me is a Podman image I built on my computer with some basic things I need (using OpenCode, but I imagine any other agent could be used instead):
FROM docker.io/archlinux:base
RUN pacman -Syu --noconfirm && \
pacman -S --noconfirm \
base-devel \
git \
curl \
uv \
opencode && \
pacman -Scc --noconfirm
RUN mkdir -p /etc/opencode
WORKDIR /workspace
From there I just run the Podman image from the command line (using a Fish function) that mounts the specific project I'm working on to /workspace. I guess there might be some vulnerabilities with shared kernels and such, but it seems like an easy way to have some isolation.
- LuD1161
With agentjail ( https://github.com/LuD1161/agentjail ), I've tried to contain coding agents in os-native sandboxes (sbpl for macos and similarly for linux, <4ms start time) + policy guardrails evaluated by Open Policy Agent (OPA), policies written in rego.
Protocol aware network proxy coming soon
Then you can match a DSL and block particular network requests.
This ensures you no longer fear --dangerously-skip-permissions and stop babysitting agents
What else would you want to see in this project? Please star the repo, if you like the idea :)
- matheusmoreira
> clawk forward add my-project 3000
> clawk network allow my-project api.example.com
Can you describe the implementation details? How did you implement the firewall without root?
I vibecoded virtdev, a virtual machine orchestration project just like this one:
https://github.com/matheusmoreira/virtdev
It was designed to not require root, and the nftables firewall ended up becoming the only exception. I'm very curious about how you implemented this. Did you find a better way?
- kstenerud
yoloAI does something similar:
- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker
- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).
- Network restriction
- Secrets control (file mounts or credentials broker)
- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one, no host-side filesystem access beyond what you explicitly allow)
- Workdir protection: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs SANDBOX side in case the repo has filters.
- Uses copy-on-write if your filesystem supports it (most modern ones do)
- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.
- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.
- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy
- MCP passthrough
- Layered API (golang) if you want to sandbox other things
- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.
- FOSS
- rvz
This is like the 30th AI sandbox project on Show HN. Why this one over the rest?
- rock_artist
> Requires macOS 14+ on Apple silicon. (Linux is supported via firecracker and currently experimental...)
So should be noted it's mostly macOS out of the box with some Linux support if I understand right.