Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

241–250 of 309 posts

Re: Annoying and alarming things about OpenCode

#241
post #164

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this: > My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it. I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? Ho…

> When did it become normal to talk about open source like this?

Why does something being open source absolve it of any sins?

Re: Annoying and alarming things about OpenCode

#242
post #200
post #164

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this: > My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it. I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? Ho…

Calling something "vibe-coded" nowadays is a permission slip to unload on it with hyperbole and insults because you can presume there's no human in the line of fire. I really don't think the people engaging in that kind of rhetoric understand how corrosive it is to the humans who do get caught in the crossfire sometimes, and to themselves for normalizing that kind of behavior.

And even so, when something is truly vibecoded it doesn't mean the vibecoder has not put a lot of love and attention into building the product.

Re: Annoying and alarming things about OpenCode

#243
post #197

Earlier quoted context omitted.

This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full cont…

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 enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).

> I don't expect them to be built into my LLM harness because I value modular software composition

I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.

Re: Annoying and alarming things about OpenCode

#245

I feel that a better title for this article would be: "Some minor annoyances that, when fixed, would improve OpenCode" # Prompt Cache Misses > It globs your filesystem and re-reads AGENTS.md (injected in turn-0 system prompt) on every SSE turn. If you put a quick note in AGENTS.md to be read in the next session, you immediately force a full re-evaluation. > Personal favourite: it puts the current date in the turn-0 s…

>> > The default system prompt is opinionated (fine) but it has shit opinions (not fine). It took me a while to figure out why my agent kept saying “Use ABSOLUTELY NO COMMENTS” when dispatching subagents. So that's why OpenCode likes to randomly remove my comments.

Opinionated system prompts forcing this are awful. It's similar to putting "ALWAYS INDENT WITH TABS" in the system prompt, but worse, because "self-documenting code" is a convenient lie lazy developers like to propagate.

I have the following in my instructions, but I often need to remind agents of it because they follow the shitty system prompt instructions:

"ALWAYS include MANY inline code comments describing what blocks of code are supposed to be doing. Inline comments serve as inline specification, a parity check between the code and the specification, and are a means to _communicate_ with all future programmers, including yourself. Write Once, Read Many. The code needs to talk to whomever is looking at it in natural language."

Re: Annoying and alarming things about OpenCode

#246

Earlier quoted context omitted.

Hey! I work on OpenCode, so thank you for this measured reply ;) Just wanted to add a few things: - We actually don't do tool-call pruning any more. But compaction is a necessary evil for the time being. There's only so much context window, and if you wish to keep working on the same task for a long time, the model needs to summarize its current progress so it can continue without hitting its token ceiling. - With V2…

Does V2 finally imminentize the eschaton? V1 has completely failed at this so far

I see what you did there ;P

Re: Annoying and alarming things about OpenCode

#247

Earlier quoted context omitted.

This seems to be quite common. You start with OpenCode (assuming you're someone who skips all the Claude Code hype); then you start thirsting for more, and switch to oh-my-pi. I generally view the kind of code in projects like OpenCode to be the same as binary machine code, and the harness that works on it is the compiler. The source code is the prompts (I guess), except we live in a weird state now we use the existi…

Yeah, this has been my progression as well. Maybe next it'll be just using plain pi when you figured out exactly what you want from omp and what you don't

No one here started with Aider? Or even text-generation-webui? Or SillyTavern? Or were they too pseudo-agentic? :)

Re: Annoying and alarming things about OpenCode

#248
> "I just don’t want to use Docker for development – if your dependencies are so sprawling that you’ve lost track of how to install them on a new machine, why do you have so many?"

I mean, there's a perfectly good solution for many of the security issues mentioned in the article... But it is dismissed because the author just doesn't "want to"?

By the way, LXC is probably better suited for reproducible build/development environments, over Docker.

Re: Annoying and alarming things about OpenCode

#250
post #9

I switched from OpenCode to Pi and there was a big improvement in terms of tool calling performance and I find the experience less buggy. OpenCode has also seemed to have disappeared from https://openrouter.ai/apps/category/coding

OpenCode requested to be removed from OpenRouter rankings: https://github.com/anomalyco/opencode/issues/11926#issuecomm...

Why is stated:

> a lot of apps run 100% of traffic through openrouter while for us it's a small subset

> but companies we were trying to work with used openrouter as a source of truth on popularity so they thought products that were much smaller were bigger than us

Post reply on HN