Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

121–130 of 309 posts

Re: Annoying and alarming things about OpenCode

#121

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

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

Re: Annoying and alarming things about OpenCode

#122

This is an anti AI post masquerading as an anti opencode port. Nevertheless I'm curious what people might suggest to use instead with local models.

Maybe https://github.com/tontinton/maki

> - Sensible permission system - when the agent runs git diff && rm -rf /, what do you think will happen in your current coding agent? It will treat it as git *. Maki uses tree-sitter to parse the bash command and figure out the permissions requested are git * and rm *. Disable using --yolo.

This sounds identical to what OpenCode does (&, contrary to their own marketing, does not seem sensible at all).

The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.

This is a security issue that has in the past been solved via explicit file-path-based allowlisting, & more recently - due to file-path matching being deemed insufficiently secure - apps have been switching to cryptographically signed binary matching as a more modern alternative to the less secure path matching. In that context, the fact these recently-written "modern" agentic clis are using a method that's more basic & even less secure than the "old insecure" method most apps use is pretty shocking.

Re: Annoying and alarming things about OpenCode

#123
post #98

Earlier quoted context omitted.

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.

And what would prevent the LLM from downloading and compiling its own version of git? But it names it "not-git".

Re: Annoying and alarming things about OpenCode

#124

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

pi.dev

Re: Annoying and alarming things about OpenCode

#125
post #47
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 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.

Re: Annoying and alarming things about OpenCode

#126

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

As tortured as you will feel after using OpenCode!

Re: Annoying and alarming things about OpenCode

#127

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

Pi or Dirge

Re: Annoying and alarming things about OpenCode

#128

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

I am on this trajectory too; opencode got me started but I tried to understand the way it is working and to do that I would normally read the source code, but the source code is really not fun.

Re: Annoying and alarming things about OpenCode

#129

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

write your own using pi.

Re: Annoying and alarming things about OpenCode

#130

Earlier quoted context omitted.

Maybe https://github.com/tontinton/maki

> - Sensible permission system - when the agent runs git diff && rm -rf /, what do you think will happen in your current coding agent? It will treat it as git *. Maki uses tree-sitter to parse the bash command and figure out the permissions requested are git * and rm *. Disable using --yolo. This sounds identical to what OpenCode does (&, contrary to their own marketing, does not seem sensible at all). The fact that…

Elsewhere in the thread someone linked to https://pleasedonotescape.com/ which is a list of sandboxes

Maybe sandboxing isn't the job for an agent harness?

Maybe choosing a VM as your sandbox, with access only to project directory.. and then enabling YOLO mode on the agent, is the way to go.

And in any case, for an agent that can write and run code, no allowlist for which programs are allowed to run is sufficient, since the agent can just write the code the program would run anyway. And the issue isn't which software the agent runs, but whether they inherit the same ambient authority as your user - read the same files as you do, modify your config files, etc. Running in a VM stops that.

Clawk (recently submitted to HN here https://news.ycombinator.com/item?id=48892859) might be good

Post reply on HN