This is slightly insane
I suppose it will be slow too if the agent needs to grep over megabytes of data
This is why ec2 and the likes all sell you access to virtual machines (dividing up their underlying hardware).
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 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.
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
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.
Also, do you restrict networking or does your container have full access to your internal network?
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.
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 :)
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?
Absence of spamming mentions of it everywhere.
> 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?
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
- 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
So should be noted it's mostly macOS out of the box with some Linux support if I understand right.
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.
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.
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.
It is possible to simply not do that. Laptops work just fine as servers. They even have a builtin monitor and UPS.
Seems like both projects are following very similar approaches.
Honestly works fine and you can use /rc to talk to them over the Claude phone app.
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.
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.
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
1. https://instavm.io/blog/nixos-reproducible-dev-environments-...
1. Tarit - https://GitHub.com/instavm/tarit
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...)
And that's without anything like prompt injection happening.
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...
Side note, just 6 days ago a Linux VM escape exploit was disclosed.
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?
CVE-2026-43499 - https://nebusec.ai/research/ionstack-part-2/
All that stuff should also go into the agent user's home directory.
Security is riddled by traps. If you can afford best possible level of isolation, why not do it?
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.
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".
Sprites arguably has the better security boundary, since the agent isn’t sitting adjacent to my laptop and home network.
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.
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.
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.
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.
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://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!
Bitrise has been doing macOS VMs for CI for 10 years, so we extended the existing product to this use-case.
[0] https://watch.ly
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.
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.
It uses cloud-init for the initial setup and injects the agent's config file and some other stuff in a ro mount from my laptop. That single subdirectory is mounted rw into a conventional location inside the VM. I inject only credentials to e.g. test environments that don't matter if they're exposed. The agent context instructs it that it can use full sudo and install any utilities from apt that it needs.
So for the ux I do incus-dev-vm.sh shell <projname> or incus-dev-vm.sh opencode <projname> etc.
A fun thing about this is I used nested virt to have the agent write the script - so I spooled up an incus VM myself first, then the agent can run with full privs inside there creating nested VMs to ensure its functionality.
Right now I'm not filtering anything on the VM - with my threat model only limited access is granted and I don't give creds to touch real infra. But you should be able to filter it on the host (I haven't researched the best approach however).
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.
Would have thrown Mythos at it if I had access to it.
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.
Did you know that before reinventing the wheel, you can ask LLM your requirements, and they can find the most suited already existing tool ?
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.
No libraries, no frameworks. Let AI recreate it from scratch … every time