The other day I upgraded my pi.dev coding harness and was testing with Qwen 3.6 35B-A3B model on my Laptop and noticed there was a slight drop in performance from the earlier version I used though the agent worked as expected. Any slight changes in the system prompts will have impact on performance and this is understandable as LLMs are non deterministic. This is the case with any harness including OpenCode. Giving coding harness its own environment (Container/VM) is the best way forward as the article denounces. Running coding agent harness without sufficient guardrails is like sitting on a time bomb. Using AI slop guardrails is still better than having no guardrails.
Annoying and alarming things about OpenCode
261–270 of 309 posts
Re: Annoying and alarming things about OpenCode
#262I 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 the…
This is absolutely true. With my constrained Intel Laptop with 16 GB VRAM, I can use both pi.dev and Qwen 3.6 35B-A3B LLM locally without much fuss. The same cannot be said about OC. Because OC loads a lot of skills by default.
Also, I am not in favor of TS for coding harness agents, is it time for a Rust based coding harness agent?
Anyone tried tau-agent? https://github.com/tau-agent/tau
Re: Annoying and alarming things about OpenCode
#263Their "OpenCode" naming is controversial too. Quoting moozilla's comment 11 months ago ( https://news.ycombinator.com/item?id=44741894 ): --- If anyone is curious on the context: https://x.com/thdxr/status/1933561254481666466 https://x.com/meowgorithm/status/1933593074820891062 https://www.youtube.com/watch?v=qCJBbVJ_wP0 Gemini summary of the above: - Kujtim Hoxha creates a project named TermAI using open-source libr…
Wrong adam. The adam who cofounded chef has nothing to do with opencode
:D
Re: Annoying and alarming things about OpenCode
#264This 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…
Eventually AI guys are gonna absorb everything, even the old tradition of angry software teardowns...
Shouldn't having all powerful chat bot give you thicker skin, not thinner?
Re: Annoying and alarming things about OpenCode
#265I also have issues with OpenCode. It induces a few facepalms and bafflement in a few key areas (“why the hell would you do it like that”).
Yet I still use it because they have made very sensible decisions in other key areas! The server/client split makes all the sense and the harness generally just works and has all the features that I want. They’ve done a great job with the core user experience.
Because of the clean client/server split, I can currently fully focus my energy on building a client that works just the way I want. When I’m done with that, I might tackle fixing the server to work the way I want.
If someone here is interested in maintaining a version of OpenCode that takes itself more seriously, I might be on board with contributing. The last time I looked such a project didn’t really exist with significant traction, unfortunately.
Despite my occasional facepalms when learning about how the stuff is made, I remain super grateful for OpenCode. It’s the only real fully-featured open alternative to the proprietary (I’ll include Codex in that) harnesses and has given me tremendous value for free.
Re: Annoying and alarming things about OpenCode
#266Earlier quoted context omitted.
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.
As for switching between sessions — it's the hierarchy that's lost on tabs.
in 1.17 I get basically a three-level hierarchy: project -> workspace -> session
I could say I rarely use more than one session per workspace (not including subagents), but switching between projects as totally separate contexts works good.
Tabs on the other hand are less organized, I can see them being fine for sessions in one project (although sidebar is more ergonomical on both desktop and mobile)
Keep in mind that this is coming from someone who has a live browser tab counter website: https://tabs.evtn.me/
Re: Annoying and alarming things about OpenCode
#267I had OoenCode couple times try to access my home folder outside the project. When I refused and asked why, it said it was "a typo" .
I believe it, but still haven't experienced it with any other model to have it make a mistake in a path. It should treat it verbatim, not interpret, should it?
Re: Annoying and alarming things about OpenCode
#268Earlier quoted context omitted.
Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area. OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.
> allowlists are not there for security I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains…
[deleted]
Re: Annoying and alarming things about OpenCode
#269Earlier quoted context omitted.
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.
Going from "build and running executables" to that needing to be done on the same system and under control of the LLM is a large leap.
Separation of duties and ephemerality are well-known security mechanisms that many harnesses jump right over in the pursuit of easier UX.
Mingling permissions + trusting vibe-coded security boundaries in the harness itself (developed by folks whose appetite for risk would make even an 00s front-end developer blush) is rolling a handful of dice all at once.
But fundamentally, this is a disagreement between two risk appetites who will never agree: {it works most of the time} vs {it's guaranteed to never fail}
Re: Annoying and alarming things about OpenCode
#270Earlier quoted context omitted.
> allowlists are not there for security I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains…
Well - pretty much everyone knows it's lousy security, because you know, it's pretty obvious. But maybe some people think it's not obvious, and point it out because they think they're clever? I suppose that's possible.
I think you're vastly overestimating the technical competence and background of most people using agentic coding harnesses today.
The downside to democratizing code creation is... it puts it in the hands of non-developers.
F.ex. a team I work with asking OpenClaw "What is SRE?"