161–170 of 309 posts
Plugin opencode-slim-system can be used to override the system prompt and the tool description for any tool (including bash). It helps a lot to fix their nonsense.
magic-context plugin fixes the compaction issues.
Run the entire process in landstrip for sandboxing to alleviate any bash concerns.
Earlier quoted context omitted.
I don't know what you mean by "enforce W ^ X". You can't give shell access and then revoke special parts of it. This is not controversial. All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY. Your complaints are misguided.
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…
I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
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…
> 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? How would you feel if someone wrote this about some software that you wrote? Reading this article made me feel extremely gross
Earlier quoted context omitted.
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 wan…
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 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…
> 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 used opencode with deepseek v4 via openrouter during the weekend. Openrouter claims a cache hit rate of about 95%. Maybe it can be improved, but it doesn't seem broken.
I agree that it is bloated, and uses a lot of memory and cpu. But I don't remember seeing any bug during its usage, or at least not big enough to notice
Earlier quoted context omitted.
I don't know what you mean by "enforce W ^ X". You can't give shell access and then revoke special parts of it. This is not controversial. All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY. Your complaints are misguided.
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…
> 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 conversation at this point because it doesn't seem productive.
Including 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.
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).