Interesting article. What are the alternatives that address the issues raised?
I see some folk recommending https://pi.dev/.
Has anyone used https://aider.chat/ and liked it?
Annoying and alarming things about OpenCode
171–180 of 309 posts
Re: Annoying and alarming things about OpenCode
#172Earlier quoted context omitted.
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 c…
Replying inline because this hit max depth: > You are confusing CPU-level security with filesystem-level security. > I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables? W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversati…
You did not hit max depth - you hit a timer designed to prevent rage posting.
My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables?
Respectfully.
Re: Annoying and alarming things about OpenCode
#173Re: Annoying and alarming things about OpenCode
#174Including the date in the system prompt - at the cost of a cache invalidation at midnight - is an entirely reasonable decision. Most other harnesses do the same thing. Including the full datetime would be irresponsible, but that's not what OpenCode does.
It felt unreasonable when I was using it at midnight and had to wait 10 minutes to refill the KV cache on my local GPU :-) A simple solution here would be to evaluate the date once per session, or once each time the `opencode` binary is launched (to avoid old, long-running sessions getting stuck in the past).
Or they could add the frozen initial starting date once at the start, then inject an additional "the date is now X" message any time midnight passes.
Re: Annoying and alarming things about OpenCode
#175Earlier quoted context omitted.
Did both of you intentionally skip the part of the article about the critical security issues?
There were 3,905 words above any mention of an RCE. Can you blame them?
there were only 110 words before it said “There are two parts to this post: annoying things and alarming things. The second part is longer.” But I agree it would be better with a table of content at the top (or on the side)
Re: Annoying and alarming things about OpenCode
#176Earlier quoted context omitted.
It felt unreasonable when I was using it at midnight and had to wait 10 minutes to refill the KV cache on my local GPU :-) A simple solution here would be to evaluate the date once per session, or once each time the `opencode` binary is launched (to avoid old, long-running sessions getting stuck in the past).
Or they could add the frozen initial starting date once at the start, then inject an additional "the date is now X" message any time midnight passes.
I was confused about how this was written in the article. Sure, include system time, or a simple get current time tool, whatever, it’s inconsequential for the most part, but who is out here changing datetimes in a conversation and invalidating prefixes?
If you need to, just prefix user messages with the current datetime.
Why is this even a complaint?
Re: Annoying and alarming things about OpenCode
#177I 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…
When I looked into opencode a few months ago I was struck by the default system prompt which came across as messy and random, iirc it also contained a typo or two. It made me look elsewhere and I didn't look back.
Re: Annoying and alarming things about OpenCode
#178This 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.
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 context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
Re: Annoying and alarming things about OpenCode
#179Earlier 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…
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.
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 existing machine code + more prompts to make even more machine code.
Re: Annoying and alarming things about OpenCode
#180I am afraid this is a very click-baity title. I actually opened the article and thought I would learn something from it.
Instead what I read was typical issues about Agentic CLI's in general dubbed as `alarming`. I would have been happy if the title was just `Annoying` which a lot of `OpenCode` is. But adding the `alarming` made it what it became, something that attracts enough eyeballs to get to the front page of HN.