https://github.com/anomalyco/opencode/releases?page=21#relea...
Personally, I run pi-agent in a custom sandbox based on bwrap, with an internet proxy. This mostly limits the blast radius to one source tree and one git checkout. And I don't give it push/pull permission. Local models are fun in a "closely supervised but slightly clueless minion" sort of way.
But all of these agents have or had "dumb" security issues:
https://github.com/anthropics/claude-code/security/advisorie...
You probably know that since you run pi inside https://github.com/containers/bubblewrap.
It has read-only access to my binaries, and I worry which programs I have might be a fingerprinting issue. I've thought about mounting a alternate /bin which using a docker image. (docker export)
Have you managed to setup any firewall or protection for the API keys? I know this is out-of-scope for bwrap.
edit: Maybe https://github.com/rootless-containers/slirp4netns could work
pi-agent famously doesn't even try to provide a sandbox, so obviously it can't have sandbox security bugs!
I actually think that this is the right model: The agent should not have access to anything it doesn't actually need: User files outside the work tree (except for maybe some allow-listed dotfiles), network access, real credentials, etc. Lock it down tight, and reduce exposure on multiple parts of the "Lethal Trifecta".
yes it's bad if the permission system is broken, but serious users have not trusted this stuff for a while, find the built-in permissions layer burdensome, and are already using a safety layer somewhere else
It'd be better if they had absolutely no permission enforcement and delegated it entirely to another program, as you say.