Hacker News new | ask | show | jobs
by JeremyNT 15 days ago
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/
3 comments
uday_singlr 11 days ago
+1 to Incus. In fact, our meta-harness of sorts, Sail, is built using Incus. The vision was to have Sail do for coding agents roughly what Kubernetes does for containers, i.e., orchestrating and dispatching engineering work to CC/Codex etc. Our small team of engineers has found decent success with this approach.
link
hsin003 15 days ago
containarium did the same thing with lxc as a container isolation and use eBPF for network safeguard. https://github.com/FootprintAI/Containarium
link
celrenheit 15 days ago
No offense taken! Curious what your actual setup looks like, and whether you do any network filtering on the incus VMs?
link
JeremyNT 7 days ago
The way I did it, I've got a convention where I store git checkouts in a specific directory on my laptop. I use the repo name as an argument and the wrapper script creates / shells into the per-project VM.

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

link