> 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
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.
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!
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.
Seems like both projects are following very similar approaches.
- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker
- Sandbox on Mac using Docker, 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 if you want to sandbox other things
- FOSS
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.
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.
It is possible to simply not do that. Laptops work just fine as servers. They even have a builtin monitor and UPS.
Bitrise has been doing macOS VMs for CI for 10 years, so we extended the existing product to this use-case.
Did you know that before reinventing the wheel, you can ask LLM your requirements, and they can find the most suited already existing tool ?
Tl libraries, no frameworks. Let AI recreate it from scratch … every time
So should be noted it's mostly macOS out of the box with some Linux support if I understand right.
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.
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
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.
Security is riddled by traps. If you can afford best possible level of isolation, why not do it?
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?
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...
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...)
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".
prairieroadent•58m ago
matheusmoreira•28m ago
hwc•20m ago
matheusmoreira•15m ago
croes•4m ago