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

151–160 of 309 posts

Re: Annoying and alarming things about OpenCode

#151

Post by kristopolous »

rafram wrote: post #15
kristopolous wrote: post #6

Opencode offers free models with 200/requests over 5 hours. That's why I use it. It is the only reason I care about. What's the alternative there? Gemini used to have free tiers. Qwen used to. AMP used to. Ollama cloud used to. Codebuff used to... None of them have those programs anymore The reason I use it is purely financial. I do not have an employer and I'm writing free software Edit: pi.dev doesn't have free inf…

There are other OSS agent harnesses.

That offer free inference?

I've written my own. I know they exist.

I don't offer free inference on large models however

Re: Annoying and alarming things about OpenCode

#152

Post by wren6991 »

qarl2 wrote: post #140
wren6991 wrote: post #136

Earlier quoted context omitted.

I mean, ideally enforce W ^ X, and enforce stricter permissions on executables where the agent has flipped the W to X. My broader point is we should be using operating system primitives instead of regex and wishful thinking.

I don't know what you mean by "enforce W ^ X". You can't give shell access and then revoke special parts of it. This is not controversial. All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY. Your complaints are misguided.

Here: https://en.wikipedia.org/wiki/W%5EX

This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.

The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.

This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.

Re: Annoying and alarming things about OpenCode

#153

Post by BeetleB »

volf_ wrote: 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

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

That's not because OpenCode is bad, but because Pi is good. I can say the same about Claude vs pi.

Re: Annoying and alarming things about OpenCode

#154

Post by cmrdporcupine »

alightsoul wrote: post #112
nylonstrung wrote: post #105

Earlier quoted context omitted.

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 minimal…

Can you name a few? I'm looking for alternatives

OpenAI's Codex tool is not limited to only calling their models. You can create a profile that uses any OpenAI API compatible endpoint.

It's written in Rust. It seems to perform well. It also seems (from my poking around in it) on the whole well and deliberately written. It doesn't consume memory like a mf'er like Claude Code. It doesn't sit and chew background CPU like I've seen opencode.

I suspect it will accumulate more specific-to-OpenAI-isms over time though.

Re: Annoying and alarming things about OpenCode

#155

Post by embedding-shape »

snapplebobapple wrote: post #121
nylonstrung wrote: post #105

Earlier quoted context omitted.

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 minimal…

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

Re: Annoying and alarming things about OpenCode

#156

Post by BeetleB »

InsideOutSanta wrote: post #125
jcul wrote: post #47

Earlier quoted context omitted.

I tried opencode and pi recently. Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog. One IIRC allows you to enable it in config and the other needs a plugin.

> Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog. There are confirmation dialogs in OpenCode. You can configure them using the permission config, same as Claude Code. Having said that, as a general rule, none of these harnesses are safe to run on your local file system.

Which is why he said "by default".

Re: Annoying and alarming things about OpenCode

#157

Post by ekidd »

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 .

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

Re: Annoying and alarming things about OpenCode

#159

Post by rafram »

kristopolous wrote: post #151
rafram wrote: post #15

Earlier quoted context omitted.

There are other OSS agent harnesses.

That offer free inference? I've written my own. I know they exist. I don't offer free inference on large models however

OpenCode Zen works with Pi, etc. It's totally separate from the OpenCode harness that this article is about.

Re: Annoying and alarming things about OpenCode

#160

Post by k-langton »

LaurensBER wrote: post #12

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…

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 (in beta atm), we have a new system for handling changing system instructions (AGENTS.md files, available skills, etc.) that avoids cache misses at all costs, while still giving the robot the newest information. I recorded a little video about it here:

https://x.com/kitlangton/status/2075749116760457346/video/1

Post reply on HN