Hacker News Reader

Comment by zyuiop | Hacker News Reader

Did both of you intentionally skip the part of the article about the critical security issues?

The RCE they mention was fixed in December, 2025:

https://github.com/anomalyco/opencode/releases?page=21#relea...

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.

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.

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

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

There were 3,905 words above any mention of an RCE. Can you blame them?

there were only 110 words before it said “There are two parts to this post: annoying things and alarming things. The second part is longer.” But I agree it would be better with a table of content at the top (or on the side)

I use nono.sh for sandboxing -- I think a lot of power users are using sandbox + YOLO mode because approval prompts slow them down

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

Which makes sense, but as long as the tool itself pretends to provide security features, the fact that these features don't work is a big problem, as it may provide a false sense of security to end users.

It'd be better if they had absolutely no permission enforcement and delegated it entirely to another program, as you say.

Reply on news.ycombinator.com