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

201–210 of 309 posts

Re: Annoying and alarming things about OpenCode

#201

Post by alanwreath »

s_ting765 wrote: post #185

The solution is not to use docker to sandbox Opencode. It is to use flatpak/bubblewrap/flatseal. I have vscode running in flatpak with directory permissions handled by flatseal. Vscode only has access to my dev folders and nothing else. Even the git bundled by vscode cannot call git push because of this (vscode doesn't have permission to read ~/.ssh!). It's an easy sandbox that's provided free of charge courtesy of b…

I’m running my development from a Mac which I think precludes flatpack usage. Pity because I love the control you have over git

Re: Annoying and alarming things about OpenCode

#202

Post by InsideOutSanta »

BeetleB wrote: post #156
InsideOutSanta wrote: post #125

Earlier quoted context omitted.

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

There are confirmation dialogs by default, though.

Re: Annoying and alarming things about OpenCode

#203

Post by tomComb »

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…

IMO, if you "put a quick note in AGENTS.md" then you should expect a cache miss.

I think that is reasonable and intuitive.

That was the first complaint I came across in the article and it made me question the level of indignation of the whole thing.

Re: Annoying and alarming things about OpenCode

#204

Post by jayair »

vitamark wrote: post #184
k-langton wrote: post #160

Earlier quoted context omitted.

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…

Can you shed some light on what's the deal with the new interface (web/desktop)? I updated one of my opencode containers today and had to downgrade it back because: 1. Worktree/workspace support is gone altogether. No way for agent to work in parallel on different things safely except prompting it directly to create a worktree. 2. Seeing multiple sessions properly now requires opening tabs for those? 3. In general, s…

Yeah it's a big change.

Workspace support is being worked on, it was half-implemented before, so we are taking a proper pass at it now.

For switching between sessions, can you tell me about your workflow from before? Because a tab can hold a session from any project. Are you saying that opening up a tab is too heavy of an action?

GitHub issues though has been a problem from us, we deal with a ton of noise/spam.

Re: Annoying and alarming things about OpenCode

#205

Post by disiplus »

dboon wrote: post #164

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this: > My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it. I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? Ho…

I found this part funny.

> People familiar with OpenCode internals (if you are on the OpenCode dev team I assume this doesn’t include you) might have objected to my python3 example above.

Re: Annoying and alarming things about OpenCode

#206

Post by slowmovintarget »

thdxr wrote: post #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…

Are there sandboxes you typically use?

I think the biggest concern from the article would be the open http server, and things like the fetched arbitrary command execution here: https://github.com/anomalyco/opencode/issues/22191

Was that issue addressed? The comment where it was marked as closed suggested it "needed more testing" but didn't have any linked PRs.

Gemini translates the closing comment as "We are closing this ticket after a quick look. The login issue is either caused by a wrong setting/external provider, or it's a deeper problem that requires someone to dig into the backend Go server code directly."

Re: Annoying and alarming things about OpenCode

#207

Post by qarl2 »

wilkystyle wrote: post #150
qarl2 wrote: 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)

Yes, exactly. This whole complaint boils down to "I don't want my changes to take effect when I make them because I don't expect that behavior."

Re: Annoying and alarming things about OpenCode

#208

Post by arcanemachiner »

simonw wrote: post #174
wren6991 wrote: post #170

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

But then someone would write an article complaining about how the newly-injected date confused their agent!

Re: Annoying and alarming things about OpenCode

#209

Post by kristopolous »

dizhn wrote: post #195
kristopolous wrote: post #151

Earlier quoted context omitted.

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

As I said in other reply there's Mimo. But I would check the opencode Go plan. First month for 5 usd and renewal at 10. (With referral offers too). If you use only deepseek flash it would take you a long way every month.

On the Opencode client it's literally 0. I haven't even signed up for an account. It's my daily driver. 0 is a powerful number

Again if I can get this somewhere else then I'm game.

Re: Annoying and alarming things about OpenCode

#210

Post by cevn »

naasking wrote: post #106
cevn wrote: post #56

Earlier quoted context omitted.

I actually share that opinion of no comment from LLMs. I just dont want to read them. So as usual, an opinion is… an opinion.

Comments sometimes help the LLM think through a problem. They are particularly useful if you have thinking disabled, eg. it's not uncommon to run Qwen3.6 locally, but its thinking is extremely verbose, so it's fast if you disable thinking, but doing that will sometimes cause it to think a little in comments, and if you disable that too, then it will produce worse output. Comments can always be stripped reliably later…

That is interesting, I had no idea comments were used in the process. I've only been using frontier models with maxed thinking, but this could be useful on the other end.
Post reply on HN