alt Hacker NewsShow HN: Clawk – Give coding agents a disposable Linux VM, not your laptop
Comments
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.
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
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 :)
> 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?
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
> 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.
If you are a Nix flake enjoyer, I whipped up something similar to this (Claude Code-only right now) based on microvm.nix: https://github.com/cdata/katsuobushi/tree/main/lib/sandbox
Some highlights:
- Drives Claude Code as a quasi-subagent via "Channels," which supports multi-turn interaction with the host and suspend / resume
- Declarative configuration in the flake of exactly what is copied into the VM (besides the local project), what DNS origins are allowed, etc.
- Shared access to host Nix store / object DB via overlay FS
- Syncs code with the host over a shared (local) Git remote (no worktree mess to manage)
- Devshell commands for quickly dropping into the guest and viewing status of all VMs etc.
- VMs start in a couple of seconds
I just use kubernetes with a single PVC for the Claude folders. Works like a charm. Don’t need too much else. You can then start separate pods with different PVCs to different folders. Lives on a server, I can manage the auth by just making each pod description different.
Honestly works fine and you can use /rc to talk to them over the Claude phone app.
If the agent is running on your machine, it will suspend when you put your laptop asleep. I prefer using a remote Linux VM to let the coding agent keep working.
I’m quite happy with exe.dev for this. My laptop is asleep upstairs but I have an agent coding away in a browser tab on the tablet I’m using. I could also check on it from my phone.
But it might also be nice if a setup similar to exe.dev were available for self-hosting. I have a Mac Mini that I don’t really use much.
Have you seen https://news.ycombinator.com/item?id=48892015 and yoloai? https://github.com/kstenerud/yoloai
Seems like both projects are following very similar approaches.
Or give them a dedicated user and you don't lose precious CPU cycles to run a VM/container: http://github.com/tarsgate/skynot
So many of these agent sandboxing solutions now. Don’t people search for existing solutions anymore?
I also wrote one where you can choose to use a container or a vm, with a MITM proxy on top https://github.com/agentcage/agentcage
Made the exact same thing when apple containers were released - https://github.com/instavm/coderunner#run-claude-code-inside...
We need an agentic platform that has sandboxing built-in well. Giving agents a disposable VM is nice but I'm already hitting my Mac mini's space limit.
Can't I just use a `docker run` command to run claude and bind in the current directory into the docker container?
I use mkosi: https://github.com/systemd/mkosi
Which is just a front for systemd-nspawn. It's annoying you have to edit the config.nspawn to mount a directory if you start it with the "shell" command, instead of booting. But apart from that, it's brilliant.
When firing up agent VMs for my personal projects, I tried to completely separate SSH keys as well. Surprisingly annoying to have multiple keys for, say GitHub, and restrict the agent to use a deploy key.
I saw this project enables ssh-agent forwarding, so my question; is this a non-issue to begin with? Or just not your focus currently.
everyone loving these linux sandboxes, even Apple wrote one https://github.com/apple/containerization/tree/main/examples...
We are building the cloud version of this: hosted, isolated VMs. MacOS and Linux supported. Cloud means you can run many VMs in parallel.
I am developing a super light similar thing here
https://github.com/daitangio/take-ai-control
It is docker + vscode friendly. I tested it with major systems (copilot, codex, Claude Code and pi.dev) Comments Wellcome!
WDYT of yolobox ? https://github.com/finbarr/yolobox
Neat, could it leverage https://github.com/apple/container
Sprites from Fly io does this beautifully, claude comes preinstalled, its great
Ok! why should I switch away from running Firejail on Fedora? Ok SUID security thanks
This is like the 30th AI sandbox project on Show HN. Why this one over the rest?
Does Codex run its own sandbox? I see that sometimes it runs commands without asking, which then fail for some reason, and it asks to run them again "outside of the sandbox"
And, make coding harnesses run 20x faster at many multi-processing and file operations by running the coding harness itself inside of Linux instead of MacOS…
the natural evolution of AI tooling: first we gave them our laptops, then we gave them VMs, next they'll demand their own AWS accounts and a corporate card
i was quite shocked to learn that cursor is not scoped to current workspace, recently it just traversed my projects dir outside my current workspace and looked for patterns in code.
I still don't understand the point of all these VMs and containers for agents. Just create a separate user on your machine without sudo privileges, switch to it in your terminal and run all the agents you want without it being able to reach your files. What am I missing?
why not just use something like smol VMs? So many VM's and I am confused on which one to use for what. I think we now need a VM orchestrator!
I use a raspberry pi for all my experiments
This is the right idea IMO but I don't want to trust a third party tool for it either (no offense OP!).
Ever since I started running coding agents with shell access I've jailed them inside of VMs. Since I run Linux I can just use incus[0] for the VM management layer.
It's extremely simple, and you can vibe code a shell script to customize your workflow in a few minutes.
Is it similar to devcontainers?
What does Clawk do that Docker without exposed ports doesn't?
How many of these are there now, a hundred? We get it, you can run an agent in a VM/container/sandbox. What about configuration management & rollbacks? What about the policy engine? What about dynamic credential management? What about the lethal trifecta? A sandbox is the easiest part and doesn't address the others.
love what youve done here. i will be using this in the future.
how does this compare with the aws lambda microvms?
> 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.
Literally everyone has the option to use a VM - it's built into Windows, UTM on MacOS, Docker on Linux. Yes, "a tool that automatically builds a VM" is useful, but we've had a third option (four, if you count "actually I disagree with the idea that it's only useful if it's fully agentic") from day one.
Is there anyone who is NOT building another AI sandbox solution?
Yet another one, only I wrote this one, so I prefer it: https://github.com/pjlsergeant/byre
You might prefer byre's simplicity, transparency, and ease of reasoning about: one local container, explicit access grants, readable generated Docker, and a workflow that stays close to normal development rather than introducing a larger sandbox platform. It's also very very easy to eject from if you want to stop using it.
[flagged]
[flagged]
[flagged]
[dead]
[dead]
Errbody gangsta until the agent figures out it's in a container and finds an exploit that lets it break out of container jail...
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.