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…
Annoying and alarming things about OpenCode
121–130 of 309 posts
Re: Annoying and alarming things about OpenCode
#122This 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
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
#123Earlier 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.
Re: Annoying and alarming things about OpenCode
#124Earlier 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
Re: Annoying and alarming things about OpenCode
#125I 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.
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.
Re: Annoying and alarming things about OpenCode
#127Earlier 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
Re: Annoying and alarming things about OpenCode
#128I 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…
Re: Annoying and alarming things about OpenCode
#129Earlier 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
Re: Annoying and alarming things about OpenCode
#130Earlier 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…
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