Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

Post reply on HN
Print view View original

281–290 of 309 posts

Re: Annoying and alarming things about OpenCode

#281

Post by qarl2 »

lucideer wrote: post #280
qarl2 wrote: post #258

Earlier quoted context omitted.

> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. You should look into "testing". It's when you run the code you just wrote to make sure it works. For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded. Anthropic's har…

You're definitely referring to fully autonomous harnesses as I suspected - these are generally quite well suited to VM deployment (quite possibly in the cloud) if you're concerned with sandboxing as they don't typically run into the same challenges as an interactive LLM UI. For ad hoc task/investigation-oriented fully interactive agent UIs the requirements are more complex & there's all a lot of advantages to running…

And now you shift the goalposts.

All of the harnesses I cited above run locally and default to testing the code they generate, despite your inability to conceive of it.

It is very obviously the primary use case: automated development interleaved with investigation. Because you need to do both, at the same time, iteratively.

Please don't make me paste those URLs again: they demonstrate exactly what you say does not happen.

Re: Annoying and alarming things about OpenCode

#282

Post by qarl2 »

lucideer wrote: post #243
qarl2 wrote: post #197

Earlier quoted context omitted.

Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area. OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.

> allowlists are not there for security I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains…

> I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance.

If you had any experience with using LLM harnesses, you would be aware that despite instructions (in prompts, AGENTS.md, etc.) the agents will sometimes ignore those instructions.

One solution to remind the agents is to explicitly disallow their instruction-violating attempts.

This is how allowlists are used to guide agent behavior.

You should try it sometime before you speak authoritatively about it further.

Re: Annoying and alarming things about OpenCode

#283

Post by jboss10 »

bel8 wrote: post #138
ekidd wrote: post #103

Earlier quoted context omitted.

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…

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 .

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

Re: Annoying and alarming things about OpenCode

#284

Post by Gander5739 »

evnp wrote: post #101
chuckadams wrote: post #7

> If you don’t know what OpenCode is, imagine a boot stamping on a human face forever. The boot is made of TypeScript and the face is everything we have learned about security and systems software since the invention of the electronic computer in the 1940s. I nominate this for a Bulwer-Lytton prize in the Tortured Metaphor category.

"There will be no curiosity, no enjoyment of the process of life. All competing pleasures will be destroyed. But always— do not forget this, Winston— always there will be the intoxication of power, constantly increasing and constantly growing subtler. Always, at every moment, there will be the thrill of victory, the sensation of trampling on an enemy who is helpless. If you want a picture of the future, imagine a boo…

Smells of AI writing - just look at those emdashes.

Re: Annoying and alarming things about OpenCode

#285

Post by caspar »

Jcampuzano2 wrote: post #111
lkjdsklf wrote: post #53

Earlier quoted context omitted.

lsp integration isn't for checks like that. It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it. It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it. How helpful all that is is h…

To be fair in every harness I've ever used that has LSP support, they never actually utilize the LSP for more deterministic refactoring tools. And even then when I do enable the LSP in many harnesses oftentimes it doesn't even use it at all. Maybe they haven't been taught to do so or it's not integrated into the system prompt or the tools but all of them only ever use the LSP to read files/symbols. Every harness I've…

This is partially a "how much does the model follow instructions" thing. I use Pi with a vibed LSP extension and Claude (4.6 or thereabouts) almost never followed instructions to use LSP renaming tools - despite it being strongly emphasized in system prompt and agents.md. However I found Codex 5.3 would use them sometimes, and GPT 5.4/5.5 would prefer them.

Re: Annoying and alarming things about OpenCode

#286

Post by ozozozd »

This is the content I come to HN for.

Talented, technical geek, with absolutely no interest in fitting in or being liked, spending a ridiculous amount of time to meticulously analyze a piece of software they clearly liked at some point, to make a list of all the ways it can be improved. Brutally honest, not for being brutal’s sake, but out of principle and out of respect for the golden rule.

OpenCode is my daily driver. And I have mad respect for the team. Basically, the only “AI people” I trust and follow. But the article is accurate. Session management leaves a lot to be desired. And most of the session management issues just need a simple 2-pointer state tracking algorithm. Its model-specific prompts are ridiculously long, and the fact that someone had enough confidence to “prompt-engineer” them and configure a harness with them is somewhat silly.

Re: Annoying and alarming things about OpenCode

#287

Post by ozozozd »

wren6991 wrote: post #239
dboon wrote: post #212

Earlier quoted context omitted.

I promise I'm not normally uptight like this, but there's a difference between having a laugh and whatever this is. Like I said, this feels (a) legitimately angry and (b) in a spit flecked enraged way that has become popular. I guess if you're cool with people calling whatever you work on clown-car turboslop then more power to you.

Author here. Just wanted to say: thank you for posting this. You've given me something to think about, and I regret writing this post the way that I did.

Absolutely not. This is what I come to HN for!

Re: Annoying and alarming things about OpenCode

#288

Post by snapplebobapple »

embedding-shape wrote: post #155
snapplebobapple wrote: post #121

Earlier quoted context omitted.

Got a link? Pi is suitably as to make search engines questionable

For the future, adding the related concepts/themes around hard to search for terms tend to do the trick. Instead of searching "go" for example, do "go programming language". Or instead of "pi", do "pi agent" or even "pi llm".

Why should the default be for me to guess in a search engine more expertly when someone is referencing a program as a suggestion instead of for them to be more explicit? I get it for things that dont live on the web but if you are going to say you replaced some program with another program the default should really be to link it especially when the name is two common characters in a common order or it is opensource imo...

Re: Annoying and alarming things about OpenCode

#289

Post by ethbr1 »

qarl2 wrote: post #274
ethbr1 wrote: post #270

Earlier quoted context omitted.

I think you're vastly overestimating the technical competence and background of most people using agentic coding harnesses today. The downside to democratizing code creation is... it puts it in the hands of non-developers. F.ex. a team I work with asking OpenClaw "What is SRE?"

Well - maybe. But as I understand it - you can't buy Mac minis right now because agentic coders are buying all of them, so they can properly sandbox their agents. Which means a LOT of people know they need to sandbox their agents. I'm beginning to think that the true issue here is that people who dislike AI are largely ignorant of the current state. Because willful ignorance. I say that because I repeatedly see peopl…

Mac Minis are out of stock because they're the cheapest entry point to reasonably capable local agents (read: 64+GB of GPU accessible RAM), which TikTok is all about.

They're being bought as a hardware solution, not a sandbox solution.

As proof, look at all the people wiring up their personal emails, etc. as soon as they turn them on.

Re: Annoying and alarming things about OpenCode

#290

Post by ethbr1 »

qarl2 wrote: post #275
ethbr1 wrote: post #269

Earlier quoted context omitted.

Going from "build and running executables" to that needing to be done on the same system and under control of the LLM is a large leap. Separation of duties and ephemerality are well-known security mechanisms that many harnesses jump right over in the pursuit of easier UX. Mingling permissions + trusting vibe-coded security boundaries in the harness itself (developed by folks whose appetite for risk would make even an…

It does not need to be on the same system - but that is currently how it is done by nearly everyone in the field because it seems to be the most effective way. Which is why coding harnesses build AND execute code. I'm not sure why you disbelieve agents can do "guaranteed to never fail". Proving correctness is one of their strengths. Proofs in general, in fact, much much better than the typical human coder.

Because guaranteed to never fail requires some UX inconveniences, and the industry (and the market) doesn't seem in a mood to tolerate inconvenience for the sake of security.
Post reply on HN