I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.
Thanks for the suggestions. I've used debootstrap to build a Debian rootfs for bwrap before, but my threat model is simpler: nothing sensitive lives outside $HOME on my machine. So I just ro-bind the system dirs I need and give the sandbox a tmpfs home (one-shot apps) or a persistent fake home (stateful apps, under ~/.var/app/<appname>). This is good enough for my case.
The gvisor layering looks promising though. I'll take a look and see if it would be useful.
I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they:
1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories).
2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exclude the tool's own hostname.
For example, with Crush, I will let it access *.openrouter.ai (LLM providers) but not *.charm.land (Crush's domain for auto-updating the LLM list).
This makes me feel much more comfortable enabling "yolo" mode and letting the tools do everything.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.