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?
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...)
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.
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 :)
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.
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?
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.
- 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.
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"
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 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.
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 told me it's a different model altogether with further fine tuning for safety or something.
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.
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...)
Side note, just 6 days ago a Linux VM escape exploit was disclosed.
Security is riddled by traps. If you can afford best possible level of isolation, why not do it?
https://bitrise.io/platform/remote-dev-environments
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.
> 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, 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
https://github.com/kstenerud/yoloai
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.
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!
Would have thrown Mythos at it if I had access to it.
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.