Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

181–190 of 309 posts

Re: Annoying and alarming things about OpenCode

#181

Earlier quoted context omitted.

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

I really, really wanted to make agent sandboxes work. Filed issues on the sandbox created by Anthropic and later also adopted by Copilot, and also to Codex repository. I think none of them is actually usable - they either allow too much or too little. There is one case where VMs are not fit, and it's when you need to do GPU work. Well unless you have gpu passthrough or virtual gpus.

I've used VMs because dealing with tool access is infinitely simpler & less fraught than tailoring sandbox profiles, but ultimately using sandbox-exec has yielded better workflows (if & when I've gotten an appropriate profile stood up). The sandbox tends to have a lot more rough edges than the VM, so I do switch back & forth between VM & sandbox, but I suspect a good sandbox-wrapping implementation with nice ux is the future.

Perhaps one could go further & combine them: e.g. a sanbox-wrapped on-host CLI that subshells/subagents out to VMs on demand. Seems potentially overcomplicated but I guess one can dream.

Re: Annoying and alarming things about OpenCode

#183
post #123

Earlier quoted context omitted.

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

It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.

Re: Annoying and alarming things about OpenCode

#184

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…

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, switching between several projects/sessions/whatever stopped working, and command palette is hotkey-only.

Issues about the new design just sit in an endless unsolved pile on GitHub which seems hopeless. And an agressive stale bot is not helping with that.

I came to OpenCode because it seemed hackable and simple, and at this point it seems like a "move fast break a lot" project that you got to live with.

(rant over, sorry if this is addressed to the wrong person, just needed to vent a bit)

Re: Annoying and alarming things about OpenCode

#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 bubblewrap/flatpak.

As someone who uses opencode regularly, the quip about it asking for permission to read logs in /tmp after already writing to the directory is pretty funny.

Re: Annoying and alarming things about OpenCode

#186

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

Heavy disagree. I can't be sure about other AI coding agents as I haven't used others enough, but especially the items around prompt cache misses and compaction have hit me personally.

This article (combined with another article previously comparing CC and OC's system prompt, to which someone replied pi.dev sends even less) has made me want to switch agents, so I'm likely going to try out pi.dev and aim to migrate.

Re: Annoying and alarming things about OpenCode

#187
post #123

Earlier quoted context omitted.

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

It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.

LLM harnesses build executables and run them. That is their primary purpose.

Changing an executable's signature by inserting a single extra printf() is well within that spec.

Re: Annoying and alarming things about OpenCode

#188

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

If you don't know what OpenCode is, imagine a dark and stormy night.

Referring to the top comment on yesterday's submission for Terranc McKenna psychadelic bad trip. https://news.ycombinator.com/item?id=48968515

Re: Annoying and alarming things about OpenCode

#189
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…

It's funny though. I haven't contributed to OpenCode but if I had I'd still laugh because I have a sense of humor. Don't take everything so seriously.

Re: Annoying and alarming things about OpenCode

#190

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…

# 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 system prompt and re-evaluates every SSE turn. If you’re using OpenCode at midnight you get a full prompt cache miss. I…

DeepSeek has a phenomenal cacheing architecture that specifically can work with less-than-ideal clients like this and get cache hits anyway.
Post reply on HN