Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

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.

  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

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 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?

- 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

https://github.com/kstenerud/yoloai

So should be noted it's mostly macOS out of the box with some Linux support if I understand right.

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

Honestly works fine and you can use /rc to talk to them over the Claude phone app.

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.

Seems like both projects are following very similar approaches.

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.

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.

https://bitrise.io/platform/remote-dev-environments

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!

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.

[0] https://linuxcontainers.org/incus/

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.

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.

Did you know that before reinventing the wheel, you can ask LLM your requirements, and they can find the most suited already existing tool ?