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

7/13/2026 at 3:35:00 PM

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.

by docheinestages

7/13/2026 at 3:40:35 PM

Gondolin[1] is what you are describing. It's made by the same person who made the Pi coding agent and sends all of the agent's bash into a small QEMU vm.

[1](https://earendil-works.github.io/gondolin/

by jboss10

7/13/2026 at 10:59:59 PM

He described a separate machine where the execution and context would be hosted, not local sandboxes. Did I misunderstand how Gondolin works?

by binary132

7/14/2026 at 8:45:47 AM

> Gondolin gives you that. Lightweight micro-VMs (QEMU by default, optional libkrun backend) boot in under a second on your Mac or Linux machine. The network stack and virtual filesystem are implemented entirely in JavaScript, giving you complete programmatic control over what the sandbox can access and what secrets it can use.

by jboss10

7/13/2026 at 5:56:21 PM

I agree with this, virtual machines are invented to solve the sandboxing/multi-tenant issues.

This is why ec2 and the likes all sell you access to virtual machines (dividing up their underlying hardware).

by binsquare

7/14/2026 at 8:00:42 AM

does eBPF be serving for security enough? ec2 is heavy in terms of cost while containarium (https://github.com/FootprintAI/Containarium) can achieve both, safe & cheap.

by hsin003

7/13/2026 at 5:02:42 PM

quickemu[0] is sort of amazing for these type of use cases actually. I feel like I could use it more for this type of stuff.

[0]: https://github.com/quickemu-project/quickemu

by Imustaskforhelp

7/13/2026 at 3:44:08 PM

I use vagrant on a seperate machine in a seperate network. The magic of ssh makes it transparent for me, and I feel pretty sure the agents cannot get to stuff that matters.

by 28304283409234

7/13/2026 at 7:53:12 PM

Exactly the same setup for me. It works great and the whole setup consists of a single Vagrantfile which I maintain via Claude itself. All relevant dotfiles are synced to a folder on the host so e.g. conversations are preserved across reprovisioning of the VM. It's a simple solution, but very flexible.

by ulrikrasmussen

7/13/2026 at 5:17:40 PM

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.

by SwellJoe

7/14/2026 at 8:02:06 AM

have you tried lxc + eBPF? the former allows you to have lighter & faster (share kernel) and the latter gives you security. that is what we do for containarium.

by hsin003

7/14/2026 at 8:52:57 AM

I used lxc many years ago and used to support it in my company's products, but for this use case, bubblewrap is the obvious answer. It's exactly the right balance of isolation and simplicity. Any full container or VM thing is much heavier than a namespace with some bind mounts, which is what bubblewrap does.

I started out implementing it with podnan, but that's also far too heavy and complicated, as you need to equip it for your specific development needs. With bubblewrap (and, thus, flar) you gave your usual environment, the whole OS mounted read only, but anything sensitive in your home or other dirs that might be sensitive is unreachable.

by SwellJoe

7/13/2026 at 3:18:16 PM

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.

by einhard

7/13/2026 at 3:38:05 PM

This is how I started, and then I wanted to bring along creature comforts, not have to re-auth per box (for subscription models), had some skills I usually wanted to bring, wanted slightly different setups for different stacks, sensibly install multiple agents, import git identity (but not credentials), mount other code folders ro but only for certain projects, etc etc, and ended up with a full Docker wrapper.

by petesergeant

7/13/2026 at 4:07:35 PM

Ah, that makes sense. I've only recently started playing with this stuff, and I've been focusing a lot of just getting somewhat good at using LLMs for projects while developing my own intuition, so everything I do just uses the mounted project and uv directly. As soon as things get more complex, I imagine I'll end up with a full wrapper as well.

Unrelated: I enjoyed your latest blog entry. I recently starting thinking about how to show the work that is done with AI, and how we talk about it. I haven't come to any major conclusions (I wish!), but your post about the prompting being distinct from the actual work resonates with me. Reminds me somewhat of discussions about the art of photography compared to the art of editing photos as a distinct skill.

by einhard

7/13/2026 at 5:25:59 PM

As opencode is inside your container, credentials and API keys are also inside the container. Prompt injection when your agent fetches some web site could have your agent leak this credentials to someone.

Also, do you restrict networking or does your container have full access to your internal network?

by qznc

7/13/2026 at 8:07:25 PM

I restrict networking via my pfSense router, using VLANs. I also don't include any credentials in the container; the agents there can't push, pull, or really access anything else beyond the standard tools without any authentication.

I don't use Claude or any other paid agent at the moment, so if that were to change I'd probably modify the way I run this, but with this simple set up I'm not too worried about credentials leaking.

by einhard

7/13/2026 at 7:29:00 PM

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 :)

by LuD1161

7/13/2026 at 8:04:15 PM

It seems like your approach depends on figuring out what the command is doing, classifying it into three tiers (deny/ask/approve) and then letting the agent run its command depending on that classification. Is that right?

by janalsncm

7/14/2026 at 6:18:11 AM

Hey thanks for the question. I would like to answer it in a more descriptive manner with an example later.

Classifying a command can be a bit of a misnomer because it has two inherent problems:

1. You need a classifier. That means the security boundary becomes “can I trick or bypass the classifier?” Whether it is a smaller model or a pile of regexes, it will eventually have edge cases.

2. The token economics do not work, and it also needs to be fast. I do not want an eval evaluating another eval for every command.

So the approach I took is closer to how we normally build security systems: secure defaults and deterministic boundaries.

For example, to protect secrets, AgentJail can block access to paths like `~/.ssh`, `~/.aws/credentials`, `.env`, etc. at the OS level.

The OS is the deterministic boundary here. The ring-0 enforcement layer.

The more interesting problem is network access. You may genuinely want the agent to debug a production Kubernetes cluster, inspect an AWS resource, or query a production database. A blanket network deny would make the agent useless.

For that, I am taking a protocol-aware DSL approach. Something like:

``` deny if { request.host == "api.github.com" request.method == "POST" startswith(request.path, "/repos/") endswith(request.path, "/git/refs") }

ask if { request.host == "kubernetes.default.svc" request.method == "DELETE" }

allow if { request.host == "api.github.com" request.method == "GET" } ```

So instead of trying to classify whether a command is “dangerous,” the policy describes exactly which resources and operations are allowed, denied, or require approval.

The agent can still be probabilistic. The enforcement boundary should not be.

Does that answer to your question?

by LuD1161

7/13/2026 at 10:24:49 PM

> What else would you want to see in this project?

Absence of spamming mentions of it everywhere.

by yencabulator

7/14/2026 at 6:07:22 AM

You mean, I should stop posting much about it ? Is it too aggressive posting Am sorry about that.

by LuD1161

7/13/2026 at 7:51:02 PM

[flagged]

by pshirshov

7/13/2026 at 2:31:37 PM

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

by matheusmoreira

7/13/2026 at 3:05:35 PM

(Years ago I had puppet and cobbler provisioning VMs over PXE and then iPXE. FWIU foreman is more actively maintained than cobbler, which is built on Django web framework.)

Vagrant manages VMs and virtual networks, in Ruby.

ansible-molecule creates, converges, and destroys VM(s) and containers, in order to test ansible playbooks and ansible roles in clean build roots.

podman machine manages VMs:

- podman-container-tools/podman-machine-os: machine image files: https://github.com/podman-container-tools/podman-machine-os/...

`podman kube play` over `podman machine` might solve for agents that need multiple VMs/containers

- Podman Desktop can work with the same local k8s setups as Docker Desktop. Though there's certainly more state to manage with k8s for agent session farm, k8s probably has better logging and quotas than a VM management script on each node.

OpenShift on OpenStack is one way to do containers over VMs over bare metal.

Microshift also does container-selinux.

There is not an apparmor policy set for containers?

bwrap and liboverlayfs and libseccomp are almost but not quite containers.

There are stronger container isolation layers that are more like a full or lightweight VM, that might be better for agent sessions: gVisor, firecracker vm, Todo

Cloudflare workerd is the open source part of cloudflare workers, which run lightweight WASM and JS VMs with multi-tenant isolation.

It takes far less resources to run a cloudflare worker than to run a container on cloudflare. So, if it's possible for an agent to operate within a WASM runtime ~container, that's probably more optimal for agent sessions.

Cloudflare/artifact-fs does lazy shallow git clones with a FUSE filesystem.

- "Show HN: VM-curator – a TUI alternative to libvirt and virt-manager" https://news.ycombinator.com/item?id=46750437

https://news.ycombinator.com/item?id=46825026 ; amla sandbox, agentvm, ARM64 MTE

https://news.ycombinator.com/item?id=46825119 ; container2wasm , vscode-container-wasm-gcc-example ; build WASM containers with Dockerfiles

docker and podman support multiple WASM runtimes for running WASM containers, e.g. for agent sessiobs

by westurner

7/13/2026 at 2:50:28 PM

Thanks! There's no packet firewall at all, no iptables/nftables. On macOS the VM's NIC is a Virtualization.framework file-handle device. The daemon runs gvproxy, which terminates the guest's connections and re-dials them as host sockets, so I filter with an allow-list right before the dial. One caveat, since you asked about root specifically: that's the macOS path, and it only works thanks to the fd NIC. Firecracker on Linux only speaks a TAP, which needs root, so there I do shell out to sudo, but just for the device. The filtering is still the same userspace allow-list.

by celrenheit

7/13/2026 at 4:00:46 PM

Thanks for the pointers!! I'm using passt, didn't know about gvproxy. This is awesome and could provide rootless filtering and firewall for my guest VMs. I'm going to experiment with this!

by matheusmoreira

7/13/2026 at 4:19:25 PM

My pleasure! You can find my fork here: https://github.com/clawkwork/gvisor-tap-vsock — the diff is tiny, just a hook in the TCP/UDP/ICMP forwarders that consults an allow-list before dialing

by celrenheit

7/13/2026 at 2:50:11 PM

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

https://github.com/kstenerud/yoloai

by kstenerud

7/13/2026 at 3:25:21 PM

Hadn't seen yoloai before. I really like new/diff/apply/destroy workflow, that's interesting. For my own needs the two things I was after were multi-repo worktrees (one sandbox spanning several repos, each on with its own worktree) and a single network restricted VM path I fully control, rather than many backends (I started with many backends at first but it was awkward to add network filtering to them). Lots of overlap though, nice work, and I'll be reading through yours.

by celrenheit

7/13/2026 at 2:48:06 PM

This is like the 30th AI sandbox project on Show HN. Why this one over the rest?

by rvz

7/13/2026 at 3:05:38 PM

Also the readme (and thus likely the whole thing) is clearly LLM-generated.

by SoftTalker

7/13/2026 at 3:28:14 PM

[dead]

by celrenheit

7/13/2026 at 3:11:40 PM

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

by rock_artist

7/13/2026 at 4:03:19 PM

mostly macOS out of the box. I've tested it on linux and it worked but it's not my daily driver. I'll make the platform scope clearer in the README

by celrenheit

7/13/2026 at 2:58:53 PM

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.

by skybrian

7/13/2026 at 3:42:00 PM

Another +1 to cloud sandboxes (and exe.dev) vs laptop sandbox.

Runs 24/7 completely air gapped from your laptop.

You also want a service proxy so the sandbox can access GitHub or Stripe without keys accessible to the agent. I haven't seen many of the laptop sandbox tools do this, where exe.dev does it out of the box with their "integrations".

I usually drop my own binary agent coding toolkit inside the sandbox so I have things like a code browsing and review right there in every sandbox too.

https://github.com/housecat-inc/scratch

Like you I also have a Mac Mini I've thought about making into my own 24/7 dev box, but building this vs buying 50 VMs from exe.dev for $20/mo doesn't add up for me.

by nzoschke

7/14/2026 at 7:52:16 AM

> but building this vs buying 50 VMs from exe.dev for $20/mo doesn't add up for me.

Assuming they never raise their prices (which they almost certainly will), you'll pay $240 per year for this. For that price you could pick up a second hand Mac mini today, though not bleeding edge I guess.

by trencedamp

7/14/2026 at 8:10:38 AM

Local first is also a feature, for work you often can't run company code on a remote VM that isn't company owned. Remote dev envs are on the roadmap though, that's one of the reasons why I designed the declarative clawk.mod manifest

by celrenheit

7/13/2026 at 3:03:55 PM

> it will suspend when you put your laptop asleep

It is possible to simply not do that. Laptops work just fine as servers. They even have a builtin monitor and UPS.

by matheusmoreira

7/13/2026 at 3:25:46 PM

Yeah but I ‘d rather run it remotely and not run agents on my laptop at all.

by skybrian

7/13/2026 at 3:01:17 PM

https://paseo.sh/ supports self-hosting, though I've only used it a mild amount tbh.

by mswphd

7/13/2026 at 3:32:21 PM

It looks like they have the right idea but their workspaces are based on GitHub worktrees rather than separate VM’s.

by skybrian

7/13/2026 at 5:05:23 PM

[dead]

by celrenheit

7/13/2026 at 4:56:54 PM

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.

by arjie

7/13/2026 at 6:02:47 PM

Amazing idea! Need to try that.

by snowstormsun

7/13/2026 at 2:45:40 PM

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.

by NortySpock

7/13/2026 at 2:51:43 PM

Funny that they're both written independently and in Go. Sometimes there's just a best way to do things I guess

by guywithahat

7/13/2026 at 3:03:23 PM

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.

by 0xbadcafebee

7/13/2026 at 4:09:09 PM

Huh. My virtdev project implements nearly all of that... Except credential injection from the host, which turned out to be on my TODO list.

by matheusmoreira

7/13/2026 at 6:32:37 PM

Based on the readme in your project, yours does not include 1) a policy engine, 2) application proxies to limit scope of access to external systems/networks, 3) firewall configuration for commonly accessed package repositories, 4) configuration management, 5) credential management.

You do have some scripts that 'diff' package inventory of the one distro you support, but not a full fledged configuration management system to manage package dependencies, file permissions, services, etc. Technically the user can deploy one using your provisioning hook but since it's not built-in it's another component the user will need to bring with them, which is one more reason they can use any other system that does basic sandboxing. I'm sure it's useful for you, but it doesn't do anything all the other solutions don't already do. You basically made Vagrant but without the useful Vagrantfile and OS-agnosticism.

by 0xbadcafebee

7/13/2026 at 8:57:24 PM

You quietly dropped rollbacks and the lethal trifecta from your list, the two exact things my project is great at. It's got qcow2 delta images and a fully customizable egress firewall backed by standard nftables.

You substituted in application proxies and firewalls for package repositories. Implementing those is what I came to this thread for. Already planning a custom network stack to replace passt. It will have those features soon. Credential management too.

> It doesn't do anything all the other solutions don't already do

That's just false. I built virtdev because I literally didn't find any other tool that implemented KVM virtualization, cheap expendable contextual VMs and configurable egress firewall with minimal, soon to be zero root access requirements. Virtdev also manages daemon life cycle correctly via user mode systemd, which is something I just don't see other projects do.

Vagrantfile and OS agnosticism are not why I built virtdev. Vagrant has no security focus at all, and I explicitly opted out of declarative YAML because GitHub Actions is painful enough.

> since it's not built-in

By this logic, no composable tool has any value. I chose to provide mechanism, not policy. The primitives are there.

> it's another component the user will need to bring with them

Yes, as files committed to a dotfiles repository. A one time configuration.

by matheusmoreira

7/13/2026 at 6:43:49 PM

shameless plug (im a contributor to): https://github.com/jskswamy/aide/ covers you, with configuration driven through yaml and credential management with sops.

by selvakn

7/13/2026 at 5:34:48 PM

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

by cdata

7/13/2026 at 6:07:54 PM

Nice I started to vibecode something with bwrap.nix: https://github.com/riedel/nix-opencode-with-mitm (not anywhere near production ready) What I would really want is token injection outside the sandbox and good control over the network, why I tried integrating a mitm proxy outside the sandbox.

by riedel

7/13/2026 at 5:43:48 PM

If you are into nixos, we at InstaVM have just launched[1] nixos based sandboxes.

1. https://instavm.io/blog/nixos-reproducible-dev-environments-...

by mkagenius

7/13/2026 at 6:03:07 PM

That's very cool, although AFAICT my hacked-together non-product shares most of the same virtues. Can you upsell it to me a little?

by cdata

7/13/2026 at 6:57:21 PM

Our nixos sandboxes are mostly a cloud offering at this time. Scale is what we can offer additionally. Have secret injection built in too. I see you have suspend, resume we have the same. We have snapshots and cloning. Startup time is sub second with warm pools - which will go further down when we replace firecracker with Tarit soon.

1. Tarit - https://GitHub.com/instavm/tarit

by mkagenius

7/14/2026 at 7:58:49 AM

Really cool project. It's fascinating to see more developers pushing back against the complexity of modern container orchestrators.

This open-sourced project called Containarium (https://github.com/FootprintAI/Containarium) recently did with a very similar philosophy: keeping container environments lightweight, simple, and highly portable.

also support MCP and eBPF for convience and security too.

by hsin003

7/13/2026 at 2:49:41 PM

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?

by vqtska

7/13/2026 at 3:04:21 PM

Privilege escalation (e.g. setuid), world-readable files might contain sensitive data, world-writeable files, unrestricted network access (including access to all locally running services)... If you have fully patched system without zero-days and it's configured in a perfect way, then, sure...

Container is quite like a "separate user" except you can explicitly define what it can access.

(Even if all your daemons have good auth, it's now quite common for _apps_ to open listening sockets without much auth...)

by killerstorm

7/13/2026 at 3:06:42 PM

Also, many of these sandboxing solutions provide features like network allowlists and credential masking/injection

by wilkystyle

7/13/2026 at 3:07:34 PM

Sure, if you assume the agent will be hostile on you. I thought it's just so the agent doesn't accidentally rm -rf / on you

by vqtska

7/13/2026 at 3:11:04 PM

The agent might install hostile software, e.g. a npm package. Unfortunately, very common problem nowadays.

by killerstorm

7/13/2026 at 4:26:57 PM

There are documented instances of LLMs casually using LPEs in order to achieve an objective: https://xcancel.com/sluongng/status/2060746160558543217

And that's without anything like prompt injection happening.

by Retr0id

7/13/2026 at 3:10:35 PM

They do try privilege escalation unprompted.

by pigeons

7/13/2026 at 2:57:11 PM

You're missing the fact you'd be sharing a kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

by matheusmoreira

7/13/2026 at 3:11:44 PM

If your threat model is that of a malicious agent that will use a 0-day LPE to get root and exfiltrate all of your SSH keys, virtualization makes sense. But then, I wouldn't run such an agent at all, if not specifically in the context of malware analysis.

If you're just concerned about "agent messing up and taking the rules in some markdown files more laxly than I would have", then running it as a seperate user is totally enough...

by zzril

7/13/2026 at 3:14:27 PM

Threat model is supply chain attacks on unmaintained package repositories like npm, pip and cargo. Everything on my host comes from my Linux distribution's repositories. Everything else gets virtualized with extreme prejudice. I'll even virtualize my Steam games one of these days.

by matheusmoreira

7/13/2026 at 3:15:58 PM

IMO the threat model is more letting the agent loose on issues/PRs in a public Github repo and it getting tricked into running a malicious payload.

by khuey

7/13/2026 at 3:04:52 PM

What kind of things are you even doing that the agent would try to perform a kernel exploit on you? I thought sandboxing is just to protect from the agent accidentally clearing your home directory.

Side note, just 6 days ago a Linux VM escape exploit was disclosed.

by vqtska

7/13/2026 at 3:12:48 PM

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. Don't want to get compromised if I install some stupid package.

My virtdev project has essentially split my computer into two systems: my "real" trusted system with software coming directly from my Linux distribition's repositories, and the VMs for everything else.

> just 6 days ago a Linux VM escape exploit was disclosed

Well, shit. Details?

by matheusmoreira

7/13/2026 at 3:41:10 PM

CVE-2026-53359 - https://github.com/V4bel/Januscape/blob/main/assets/write-up...

CVE-2026-43499 - https://nebusec.ai/research/ionstack-part-2/

by rvz

7/13/2026 at 4:23:02 PM

Patched in Linux 7.1.3, which happens to be the exact kernel version I'm running. Update your kernels, folks.

by matheusmoreira

7/13/2026 at 3:51:59 PM

> npm, pip, cargo and everything else

All that stuff should also go into the agent user's home directory.

by SoftTalker

7/13/2026 at 2:51:43 PM

VMs and containers are fairly isolated and reproducible. A separate user on your machine still depends on the programs installed locally.

by bheadmaster

7/13/2026 at 3:04:13 PM

And those installed programs could have vulnerabilities that just a non-root user account could still take advantage of. Perhaps not likely for an LLM to do, but more so if you let them loose on the internet and they end up coming across prompt injection that instructs exactly that :)

by Greenpants

7/13/2026 at 2:56:23 PM

Well, for one, Debian and Debian-based distros make your home directory readable by everyone by default.

Security is riddled by traps. If you can afford best possible level of isolation, why not do it?

by 3form

7/13/2026 at 5:43:46 PM

Yep, I broke locate when I made my home 700. Its user could not traverse my files anymore. I had to make it run as root. A better design would be to traverse each user home with that user id but apparently it assumes that the home dirs are 755.

by pmontra

7/13/2026 at 2:52:35 PM

you can also simply use Landlock and bwrap on Linux. Pi even has a plugin for that https://pi.dev/packages/pi-landstrip

by bpavuk

7/13/2026 at 3:07:26 PM

Codex uses bwrap sandbox which is purely cosmetic - out-of-box it sees your ssh keys and can send it to remote server. It prevents agent from deleting outside files by mistake, but does nothing against malicious activity

by killerstorm

7/13/2026 at 3:13:50 PM

that Pi extension, by contrast, gives you a popup whenever an agent tries to access something outside the current working directory and send a network request. that depends on configuration. also if agent tries to ssh into something that will also send a request for access, so child processes are covered

by bpavuk

7/13/2026 at 3:04:42 PM

Actually that doesn't just work on all systems and it breaks on others. The alternate user is actually guaranteed to work on all systems and it's built in

by 0xbadcafebee

7/13/2026 at 3:17:13 PM

Seatbelt on macOS and Landlock over WSL2 on Windows 11. Landlock is also built-in, and WSL2 is a first-party downloadable component

by bpavuk

7/13/2026 at 3:47:17 PM

There are two sides to this. The first is security, which plenty of comments already covered. The second, and the real one for me: my tests spin up Docker containers, and I was building a Kubernetes tool (argocd/flux style) that needs a real cluster in the sandbox. In a container that means Docker-in-Docker, which always felt hacky. A VM is just a normal Linux box where Docker and k8s run like they do everywhere else. A separate user can't give you that, it shares your one kernel and whatever's already installed on the host.

by celrenheit

7/13/2026 at 3:32:24 PM

There is a reason why VMs even are a thing at all: they can offer better security guarantees than alternatives.

A separate user is a good start but LLM tests themselves show they can cleverly bypass guardrails if they figure out they are in a sandboxed environment of some kind, right?

So, I read those test results as: an LLM is less likely to do something crazy if it thinks it has the whole environment to itself.

by schainks

7/13/2026 at 3:10:15 PM

On my Mac, every sudo requires either my fingerprint or password, and times out immediately.

by de6u99er

7/13/2026 at 3:38:29 PM

Colleague recently told me his agent tried to sudo. It failed but it saw that docker with root is available and just used that. I don't quite remember what it did, I think editing something in /etc.

by qznc

7/13/2026 at 3:15:21 PM

And why would I do that when I can create a vm from a snapshot and be done in 30 seconds?

by throw1234567891

7/13/2026 at 3:10:42 PM

Mainly networking and namespaces, same reasons why we run services on docker instead of old multi-user setups

by augusto-moura

7/13/2026 at 3:21:43 PM

If you think those two contexts are equally secure, your machine is incredibly insecure and I hope you run daily incremental full system backups.

You have far too much data in unsecured locations, and you have far too little understanding of what an agent would do, to go "I trust whatever this user account will be doing on my machine".

by TheRealPomax

7/13/2026 at 2:51:17 PM

In a corporate environment they may not have that option

by altcognito

7/13/2026 at 3:04:22 PM

But they can run arbitrary VMs?

by SoftTalker

7/14/2026 at 6:26:47 PM

Doesn't have to be arbitrary, and managing users requires a lot more nuance (endless permission toggling/configuring) than just running a VM that is more of a whitelist.

by altcognito

7/13/2026 at 2:56:04 PM

am I doing that once per project, or?

by petesergeant

7/13/2026 at 4:11:04 PM

Or give them a dedicated user and you don't lose precious CPU cycles to run a VM/container: http://github.com/tarsgate/skynot

by knocte

7/13/2026 at 3:09:20 PM

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

by lucamartinetti

7/13/2026 at 2:33:22 PM

Sprites from Fly io does this beautifully, claude comes preinstalled, its great

by bad_haircut72

7/13/2026 at 3:53:24 PM

The core abstraction seems identical to Fly.io Sprites: give the coding agent its own real Linux machine, put a hard network/isolation boundary around it, then yeet.

Sprites arguably has the better security boundary, since the agent isn’t sitting adjacent to my laptop and home network.

by whitlock

7/13/2026 at 3:19:36 PM

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

by TheRealPomax

7/13/2026 at 4:01:49 PM

[dead]

by celrenheit

7/14/2026 at 3:01:42 PM

I've been building watch.ly[0] which intercepts all network /fs traffic on the machine originating from the agent and pings you for approval.

[0] https://watch.ly

by winrid

7/13/2026 at 2:36:34 PM

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.

by felooboolooomba

7/13/2026 at 4:18:25 PM

Can't I just use a `docker run` command to run claude and bind in the current directory into the docker container?

by djha-skin

7/13/2026 at 5:17:09 PM

Check the 2nd section of article https://github.com/clawkwork/clawk#why-a-vm

A lot of people would yell "docker isn't secure!" but if you're running Docker on MacOS (and Windows, I think) you're already running a Linux VM. But if you really wanna let your agent YOLO their way along, Docker is kinda restrictive, so that a full VM lets it install things, start services, and so on.

by kerblang

7/13/2026 at 9:43:31 PM

So many of these agent sandboxing solutions now. Don’t people search for existing solutions anymore?

by als0

7/13/2026 at 10:32:13 PM

I'm afraid not. My impression is, most are just prompting for the tool they need right now, accept bugs and maybe even security gaps, but save time and pain not searching for an established tool. Which is fine and understandable for private things. But I wonder, how often this happens in professional environments. But maybe I'm just wrong... I have not seen any resarch or evaluation for this claims. Would be interesting, though

by lschueller

7/13/2026 at 3:15:22 PM

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.

by statt

7/13/2026 at 3:06:53 PM

everyone loving these linux sandboxes, even Apple wrote one https://github.com/apple/containerization/tree/main/examples...

by c0rruptbytes

7/13/2026 at 3:00:35 PM

We are building the cloud version of this: hosted, isolated VMs. MacOS and Linux supported. Cloud means you can run many VMs in parallel.

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

by dietdrb

7/13/2026 at 3:09:54 PM

It's called https://github.com/features/codespaces or https://codeanywhere.com/ or https://claude.ai/code/

by mrbn100ful

7/13/2026 at 3:19:04 PM

None of the products you mentioned support macOS environments needed by iOS/tvOS/etc developers. (CodeAnywhere went out of business)

Bitrise has been doing macOS VMs for CI for 10 years, so we extended the existing product to this use-case.

by dietdrb

7/13/2026 at 3:27:19 PM

I guess you have macOS, but that just it.

by mrbn100ful

7/14/2026 at 8:07:42 AM

But that's the it!

by fragmede

7/13/2026 at 2:35:48 PM

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!

by daitangio

7/13/2026 at 5:36:31 PM

Made the exact same thing when apple containers were released - https://github.com/instavm/coderunner#run-claude-code-inside...

by mkagenius

7/13/2026 at 2:55:56 PM

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"

by aftbit

7/13/2026 at 3:27:06 PM

Yes, Codex has its own sandbox which you can disable: https://learn.chatgpt.com/docs/sandboxing?surface=app

Cursor has something similar. I don't know about Claude Code but I assume it does as well since Anthropic has open sourced their own sandboxing tool.

by RussianCow

7/13/2026 at 7:12:22 PM

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.

by sxiong

7/13/2026 at 8:14:49 PM

Fly.io’s sprites.dev is a similar idea but on their hardware and you get a public/private domain to run a server too, I’ve found it pretty good.

by mcintyre1994

7/13/2026 at 7:18:58 PM

Claude Cowork does this on Mac and ears several gigabytes of on disk storage, drives me crazy, because it does this if you click on it without ever using it.

by giancarlostoro

7/13/2026 at 8:49:03 PM

[flagged]

by zhshhan

7/13/2026 at 5:02:28 PM

Neat, could it leverage https://github.com/apple/container

by antihero

7/14/2026 at 7:47:47 AM

It was leveraging apple container in the first versions. They have the same foundation VZ (Virtualization.framework), build one container per VM. The reason I stayed with raw VZ instead of apple container is the network filtering feature

by celrenheit

7/13/2026 at 5:16:24 PM

WDYT of yolobox ? https://github.com/finbarr/yolobox

by asah

7/13/2026 at 3:14:00 PM

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…

by ttul

7/13/2026 at 4:24:01 PM

That's actually how clawk runs it: the agent process (claude/codex) runs inside the Linux guest on a PTY, not on macOS

by celrenheit

7/13/2026 at 3:15:14 PM

Is file IO a bottleneck now?

by mlnj

7/13/2026 at 6:29:28 PM

A lot of the work that coding agents do requires tons of random access to files, which MacOS is particularly slow at. Not because the hardware is bad, mind you. Mac SSDs are amazing. It’s the file system. Secondly, MacOS supervises processes for security reasons and coding harnesses spawn tons of processes. There is a lot of CPU overhead embedded in that supervision.

by ttul

7/14/2026 at 9:26:40 AM

Been working on something similar, love to see more project in this area

by onel

7/13/2026 at 6:52:48 PM

Ok! why should I switch away from running Firejail on Fedora? Ok SUID security thanks

by polotics

7/13/2026 at 3:18:09 PM

Is it similar to devcontainers?

by thiodrio

7/13/2026 at 4:36:21 PM

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.

by grzes

7/13/2026 at 3:42:55 PM

What does Clawk do that Docker without exposed ports doesn't?

by oleg_kabanov

7/13/2026 at 6:40:00 PM

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

by luciana1u

7/13/2026 at 2:50:45 PM

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!

by anoop_kumar

7/13/2026 at 3:50:00 PM

I use a raspberry pi for all my experiments

by windex

7/13/2026 at 5:32:30 PM

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.

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

by JeremyNT

7/14/2026 at 8:54:39 AM

containarium did the same thing with lxc as a container isolation and use eBPF for network safeguard. https://github.com/FootprintAI/Containarium

by hsin003

7/14/2026 at 7:56:14 AM

No offense taken! Curious what your actual setup looks like, and whether you do any network filtering on the incus VMs?

by celrenheit

7/13/2026 at 2:24:58 PM

why not just a docker container

by prairieroadent

7/13/2026 at 2:54:38 PM

Because that means you are sharing kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

by matheusmoreira

7/13/2026 at 3:02:42 PM

If there is any attack surface within a properly-configured container, that's a kernel bug, right?

by hwc

7/13/2026 at 3:07:03 PM

Probably. If I remember correctly, containers on Linux are implemented using the kernel's namespaces. The same ones which became famous for the vulnerabilities they surfaced in previously unexercised code.

by matheusmoreira

7/13/2026 at 3:18:32 PM

Then use SmolVM

by croes

7/13/2026 at 3:27:22 PM

I'm already using virtdev, my own solution built on top of QEMU.

by matheusmoreira

7/13/2026 at 2:31:08 PM

love what youve done here. i will be using this in the future.

by ebeirne

7/13/2026 at 3:07:07 PM

Thank you, that means a lot !

by celrenheit

7/13/2026 at 2:52:07 PM

how does this compare with the aws lambda microvms?

by htrp

7/13/2026 at 3:14:01 PM

Is there anyone who is NOT building another AI sandbox solution?

by mlnj

7/13/2026 at 2:55:49 PM

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.

by petesergeant

7/14/2026 at 11:17:31 PM

[flagged]

by ericmaciver

7/14/2026 at 3:56:02 PM

[flagged]

by joshsantiago01

7/13/2026 at 3:02:35 PM

[flagged]

by elombn

7/14/2026 at 11:19:25 AM

[dead]

by jaichaprana

7/13/2026 at 2:18:44 PM

[flagged]

by sumar7

7/13/2026 at 6:49:25 PM

[flagged]

by ronalder100

7/13/2026 at 5:28:08 PM

[dead]

by linggen

7/13/2026 at 3:16:00 PM

[dead]

by escape_42

7/13/2026 at 2:33:20 PM

Errbody gangsta until the agent figures out it's in a container and finds an exploit that lets it break out of container jail...

by bitwize

7/13/2026 at 2:35:34 PM

I developed a VM project just like this one. Asked Fable to stress test it and try to break out of containment, and to my surprise it didn't manage to. Fable didn't get downgraded to Opus either, for some reason.

Would have thrown Mythos at it if I had access to it.

by matheusmoreira

7/13/2026 at 2:49:17 PM

Isn't Fable just Mythos + guardrails? Sounds like you did throw Mythos at it.

by arcanemachiner

7/13/2026 at 2:58:59 PM

I initially thought that was the case: literally the same weights but with an incredibly obnoxious "safety classifier" tacked on. Now I'm uncertain because people on HN have told me it's a different model altogether with further fine tuning for safety or something.

by matheusmoreira

7/13/2026 at 3:08:41 PM

You should conduct the same test with knowingly faulty containment, otherwise the theory that the model is hobbled should probably outrank that it couldn't escape.

by nullc

7/13/2026 at 3:18:30 PM

That's a good idea. I don't have Fable at the moment, when it comes back I'll ochestrate those tests.

Opus did manage to iron out a lot of fail open bugs during development though, and Fable's like a hundred times more relentless than Opus. I'm not saying it's a definitive result or that my VM firewall thingy is unhackable... I'm just saying it put a smile on my face.

by matheusmoreira

7/13/2026 at 3:06:06 PM

YAY, let's build the same thing over and over :/

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

by mrbn100ful

7/13/2026 at 3:47:11 PM

Yeah, but I explicitly chose to make my own anyway because I wanted to fully own the code and none of the existing solutions worked the way I wanted.

There is absolutely nothing wrong with reinventing the whell. It's entirely possible to do it and end up discovering you've made a better wheel.

by matheusmoreira

7/13/2026 at 3:19:58 PM

Isn’t the point of LLM to recreate the wheel?

No libraries, no frameworks. Let AI recreate it from scratch … every time

by croes

7/13/2026 at 3:55:24 PM

`vagrant snapshot` exists.

by 28304283409234