Hacker News new | ask | show | jobs
by ekidd 8 days ago
It is a pretty catastrophically dumb CVE, of the sort that makes me not want to allow OpenCode anywhere near any of my machines in the future. It was basically "RCE as a service", not some subtle bug.

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.
1 comments
bel8 8 days ago
I too love and use pi agent.

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.

link
jboss10 7 days ago
I use this setup as well. I've written an alias for bwrap which only gives the agent access to the current directory and read only access to the docs.

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

link
ekidd 8 days ago
Those are Claude Code security issues? And Claude Code is a gigantic vibe-coded dumpster fire with more bugs than an ant hill?

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

link