Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

141–150 of 309 posts

Re: Annoying and alarming things about OpenCode

#141
I find it absurd that a TUI desktop app is heavier than a native one AND heavier than most browser based desktop apps, it's so much waste of RAM, CPU, energy/battery just to show text.

I've been working on my own AI harness/chat in C++ Qt6[1] and it's lighter than anything else even with lots of features like sub-agents, code diff, terminal emulator, simple editor, markdown preview, translucent background, custom themes, permissions, MCP, git integration(commits, stage, diffs), dock system to move elements and tabs for projects; but it's not released yet as I want to polish it a bit, remove a few bugs I found and simplify the UI.

[1]: https://zeteo.krysoph.com/preview.html

Re: Annoying and alarming things about OpenCode

#143
post #68

Earlier quoted context omitted.

Definitely agree on the title. Also could have worked as 'Some minor annoyances that, when fixed, would improve OpenCode. Also, I don't like AI"

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?

Re: Annoying and alarming things about OpenCode

#146
not too much actionable here. most of the more glaring issues are already fixed in our upcoming v2 if you'd like to try beta: https://x.com/thdxr/status/2075636594640376165

some things mention are outdated - particularly the tool call pruning feature. this has been disabled by default for a while specifically because of complaints like this

when we looked through our data it's not so clear cut that it's net negative https://x.com/thdxr/status/2048268697790300343

also i'm pretty excited about our new system prompt approach - can define each component in a way that avoids busting the cache when they change. eg that midnight issue: https://x.com/thdxr/status/2070721003924103651

providers (anthropic is the first) are supporting this as a native concept

Re: Annoying and alarming things about OpenCode

#147
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 purged OpenCode when I noticed it downloads npm packages in the background without asking the users first. This exposes higher risk of supply chain attach risk.

Re: Annoying and alarming things about OpenCode

#148

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…

That's the thing. You can't change it. They do not accept PRs from what I've seen. Whilst it's open source it's only in name. There may be the odd PR accepted from outside the team. But very very rarely. It's honestly embarrassing to call this open source. Pi on the other hand, whilst they have their own unique issues with PRs, if you came to them with a genuine problem, or fix, they seem to accept it. Now I point ba…

Open source doesn't mean that it has to accept PRs. It has never meant that the code author's must accept community contributors.

OpenCode has an MIT license, which allows you to copy/fork the code and modify it how you see fit.

Please review the open source initiative's definition of open source: https://opensource.org/osd

Re: Annoying and alarming things about OpenCode

#149

Earlier quoted context omitted.

> - 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, sin…

I've run agentic CLIs in a sandbox (using MacOS sandbox-exec) & in VMs - both solutions have an inherent advantage over any integrated sandboxing by virtue of their independence (even before we get into configurability). Claude CLI integrates sandbox-exec internally, but I can't really trust it completely because Anthropic don't really have any vested interest in restricting their own tooling on my machine - they want me to rely on the tooling more, not less, which naturally entails granting the tool broader access: this is reflected in two ways in their sandbox-exec implementation: (1) it's wrapped in a relatively lax default profile & (2) not everything the cli does is sandbox-wrapped.

All that said, I don't think I'd agree that sandboxing doesn't belong in the agent harness. Ultimately, I want to be using an open source cli tool that doesn't come with the above Anthropic perverse incentives. The advantage of using a separate sandbox solution with Claude CLI isn't that it's separate, it's that I control it. Ideally I should control my agentic cli though, & in that context, bundling the sandbox comes with a lot of inherent advantages.

Unfortunately, as far as I've seen, the current batch of open source clis are pretty poor at the above, leaving little incentive to switch from proprietary solutions.

Re: Annoying and alarming things about OpenCode

#150
post #58

> 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. Um. Which then gets immediately cached again. I prefer this behavior. I prefer my changes incorporated immediately, rather than wait for the next session. Call me crazy. (Author is unhinged and this stor…

Also, aren't instructions earlier in the prompt treated with more weight than those that occur much later? Sure, you could insert the system prompt later to avoid re-caching as much, but then the system prompt (if I am understanding correctly) carries MUCH less weight.

(And also your point about immediately being re-cached a good one)

Post reply on HN