I'm using it as my main driver since months.
Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)
It has network filtering + placeholders for secrets.
OSS, no logins needed
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.
Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.
Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.
What I don‘t have compared to sbx is an outbound firewall, but my VM does not have any personal/interesting data, only a vanilla Fedora installation and the project dir with open source code, so I do not care much about exfiltration.
thanks
So I wrote a wrapper around Gondolin which allows me to do that and a few other things: https://github.com/codethief/tuor
(Warning: Still very much experimental / underdocumented.)
It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself?
Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.
And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.
Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.
https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want
https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want
Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.
Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.
There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.
Wrote the whole setup up here, in case it's useful:
https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-...