Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

101–110 of 309 posts

Re: Annoying and alarming things about OpenCode

#101

> 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 boot stamping on a human face— forever."

George Orwell, 1984

Re: Annoying and alarming things about OpenCode

#103
post #83
post #68

Earlier quoted context omitted.

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.

Re: Annoying and alarming things about OpenCode

#104

Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all. These are all just some minor annoyances, some disagreements, and most importantly, a fundamental misunderstanding of the point of command filtering. It is not for security, it’s for steering. Anyway, it didn’t sound like the author tried building anything with OpenCode, and if they did, they said noth…

>Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all.

I feel the same way. It's the right amount of 'gets out of my way' and 'won't nuke my machine'.

Especially the ease of using Plan mode and quickly getting stuff done.

Re: Annoying and alarming things about OpenCode

#105

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 bigger point is that the codebase is hopelessly bloated by vibe coded features at this point, mirroring the same problems with Claude Code. And stability, performance, memory use have all gotten terrible.

I liked Opencode a lot previously but there's no doubt it's not well-written software. Pi has fully replaced it for me and there are quite a few newer options that learned from Opencode and exercise more minimalism where it matters

Re: Annoying and alarming things about OpenCode

#106
post #56

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…

I actually share that opinion of no comment from LLMs. I just dont want to read them. So as usual, an opinion is… an opinion.

Comments sometimes help the LLM think through a problem. They are particularly useful if you have thinking disabled, eg. it's not uncommon to run Qwen3.6 locally, but its thinking is extremely verbose, so it's fast if you disable thinking, but doing that will sometimes cause it to think a little in comments, and if you disable that too, then it will produce worse output.

Comments can always be stripped reliably later.

Re: Annoying and alarming things about OpenCode

#107
The mix of humanizing the LLM, calling it "clanker" and being very aggressive towards it is really weird. I don't think it's a good habit to take, it feels like it could bleed into how you interact with people. Many interactions are through text interfaces these days.

Re: Annoying and alarming things about OpenCode

#108
post #54
post #33

Their "OpenCode" naming is controversial too. Quoting moozilla's comment 11 months ago ( https://news.ycombinator.com/item?id=44741894 ): --- If anyone is curious on the context: https://x.com/thdxr/status/1933561254481666466 https://x.com/meowgorithm/status/1933593074820891062 https://www.youtube.com/watch?v=qCJBbVJ_wP0 Gemini summary of the above: - Kujtim Hoxha creates a project named TermAI using open-source libr…

Wrong adam. The adam who cofounded chef has nothing to do with opencode

[deleted]

Re: Annoying and alarming things about OpenCode

#109
post #25
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

How you deal with LSP? One of the best things in OpenCode is LSP integration.

I disliked OpenCode's LSP integration, as Pyright kept distracting the model from what I wanted done in a Django project. I prefer to run MyPy at my own convenience

Re: Annoying and alarming things about OpenCode

#110
post #98

This is a good summary of the dangers of using agentic clis, but the title & general focus on opencode is odd for two reasons: 1. Most obviously & importantly this is a complaint without a straightforward suggested alternative. A sibling commenter mentions suggesting fixes to Opencode would be more productive: I don't necessarily agree since many of these issues are fundamental & would likely require an almost ground…

I wonder how he imagines you can give shell access but securely prevent arbitrary command execution. His complaint that "echo git | bash" still works is particularly nutty.

Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).

This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.

Post reply on HN