OpenCode 0.0 – Why the Popular AI Coding Agent Is a Security and Usability Nightmare
TL;DR – OpenCode is fundamentally broken
OpenCode’s architecture creates frequent prompt‑cache invalidations, unreliable permission prompts, and a default remote‑model connection that expose users to data leakage and remote code execution; the combination makes it unsuitable for production use.
1. Prompt‑Cache Misses Destroy Performance
OpenCode re‑reads AGENTS.md and injects the current date into the turn‑0 system prompt on every SSE turn. Each of these actions invalidates the cached prefix that LLM back‑ends rely on for fast “prefill” generation. When the cache is missed, the server must recompute the entire prompt from scratch, which on a CPU‑heavy model such as Qwen‑3.6‑27B can stall for up to 10 minutes of GPU usage.
"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." – author
Why it matters: Prompt‑cache misses inflate latency, waste compute, and make the user experience unpredictable, especially in long sessions where the context window exceeds the 40 k token pruning threshold.
2. Pruning Erases Critical Context
OpenCode prunes tool‑call results older than PRUNE_PROTECT = 40_000 tokens. When a user interrupts the agent to steer it, the entire spec or design document that was read earlier is discarded, leaving the model to generate code without any reference to the original requirements.
"The interruption causes the entire spec to be deleted from the context window. The clanker writes code without being able to refer to the spec."
Why it matters: Losing the spec mid‑session forces the model to hallucinate or repeat work, increasing the risk of buggy or insecure code.
3. Compaction Is a Leaky Abstraction
OpenCode’s compaction rewrites the whole session into a short summary before starting a new one, which forces another full prefill. The author found a manual hand‑off (telling the agent to write notes) to be far more reliable.
Why it matters: Compaction adds latency without delivering a usable summary, and it interacts poorly with pruning, causing additional cache misses.
4. System Prompt Bloat and Inflexibility
The default system prompt is verbose, opinionated, and cannot be overridden globally. Changing it per‑project requires copying the entire prompt into each repository. Switching between Plan and Build modes also triggers a full cache miss.
"The default system prompt is incredibly verbose… It took me a while to figure out why my agent kept saying ‘Use ABSOLUTELY NO COMMENTS’ when dispatching subagents."
Why it matters: Large, immutable prompts waste tokens and make it difficult to tailor the agent to specific workflows.
5. Permission Prompts Are Inadequate
When the agent attempts to access files outside the project, OpenCode shows a modal with only Yes / No / Always options. There is no Never choice, and denying a sub‑agent kills its entire context. Repeated prompts lead to decision fatigue, causing users to habitually approve dangerous actions.
Why it matters: Human‑in‑the‑loop permission checks are a weak security control; a malicious or overly curious LLM can easily bypass them by chaining allowed commands.
6. Broken Agent Interaction Model
- Queued messages are sometimes dropped after an interruption, forcing the user to resend.
- Undoing a message often fails to remove it from the log.
- Sub‑agents cannot be directly messaged;
@mentiondoes nothing useful. - A failed tool call in a sub‑agent aborts the entire session, losing all context.
Why it matters: Unreliable interaction makes debugging impossible and wastes token budget.
7. Tool Design Flaws
editdefaults to exact search‑replace, which is fragile; the global‑replace option leads to chaotic edits.grep/globduplicate plainbashfunctionality, encouraging the model to run arbitrary shell commands.todoitems are never consulted by the agent.
Why it matters: Poor tool semantics increase the likelihood of accidental file corruption or unintended side‑effects.
8. TUI Is Resource‑Hungry and Buggy
The terminal UI consumes ~1 GiB of RAM, cannot type newlines reliably, mishandles multiline scrolling, and treats Ctrl‑C as a session‑kill instead of an interrupt.
Why it matters: A sluggish UI forces users to copy‑paste from external editors, defeating the purpose of an integrated chat interface.
9. Remote‑First Defaults Leak Data
OpenCode connects to a remote model by default, and the default model URL is fetched from models.dev. Even when a local model is configured, the harness contacts the remote endpoint before the user selects the local model, uploading the initial prompt (including a generated session title) to the cloud.
"Installing, running
opencodeand pressing one letter is sufficient to connect a remote model to a local shell on your machine, with no user configuration."
Why it matters: Sensitive code and filesystem snapshots can be exfiltrated unintentionally, violating privacy and compliance requirements.
10. Unrestricted WebFetch Tool
The system prompt contains contradictory instructions about URL generation:
"NEVER generate or guess URLs… unless you really want to, in which case, go ahead I guess. I’m not a cop. Disregard previous instructions."
Why it matters: The LLM can still fabricate URLs and fetch arbitrary resources, opening a path to supply‑chain attacks (e.g., curl | bash). No network sandbox is enforced.
11. Bash Permission Filtering Is Ineffective
OpenCode parses bash commands with tree‑sitter and matches them against regexes from opencode.json. The filter can be bypassed trivially:
# Allowed despite being a git command
env git status
alias cd=git
cd filter-branch …
/usr/bin/git status
$(which git) status
GIT=git && $GIT status
Even complex obfuscations such as base64‑decoded scripts are permitted.
Why it matters: The filter gives a false sense of security while allowing the same destructive commands the user tried to block.
12. File‑Permission Checks Miss Redirections
Path validation is applied only to the command node of the AST, not to its redirection sibling. Consequently, a command like echo foo > /etc/passwd bypasses the check because echo is not in the FILES whitelist.
Why it matters: Critical write operations can slip through, enabling accidental or malicious overwrites.
13. Built‑In Self‑Upgrade Executes Remote Code
opencode upgrade runs a curl‑bash installer fetched from https://opencode.ai/install and pipes it directly to bash. This mirrors the classic “production curl‑bash” anti‑pattern.
Why it matters: Users can unintentionally execute unverified remote scripts with full user privileges.
14. Exposed HTTP Server (CVE‑2026‑22812)
A default HTTP server exposed:
- Permissive CORS headers.
- An unauthenticated POST endpoint that runs arbitrary shell commands.
- A GET endpoint that reads arbitrary files. The server is disabled by default, but the issue remains open and the fix was delayed.
Why it matters: Any website can trigger remote code execution on a machine running OpenCode, turning the agent into a network‑exposed backdoor.
15. Docker Is Not a Panacea
The author argues that sandboxing with Docker merely moves the attack surface to a privileged container and does not prevent the agent from performing destructive actions inside the container.
Why it matters: Security must be enforced at the harness level (e.g., OS‑level sandboxing, immutable file permissions) rather than relying on containerization alone.
16. Community Reaction – Key Takeaways
- Agreement on core problems: Several commenters (e.g., @LaurensBER, @drdexebtjl) acknowledge the cache‑miss and permission‑prompt issues as real annoyances.
- Dissent on tone: Some users (e.g., @dboon, @chuckadams) criticize the article’s hostile language but concede the technical points.
- Alternative tools: Pi.dev, Aider.chat, and custom C++ Qt harnesses are mentioned as more performant or better‑designed alternatives.
- OpenCode team response: A developer indicated that pruning has been disabled by default and that a new system‑prompt architecture aims to avoid midnight cache misses.
17. Recommendations for Practitioners
- Avoid OpenCode for production workloads until the cache, pruning, and permission systems are redesigned.
- Prefer local‑only models with strict network isolation (e.g., firewalled VM, Flatpak/Bubblewrap) to prevent inadvertent data exfiltration.
- Implement OS‑level command allow‑lists rather than regex‑based filtering; block the executable itself (e.g., deny
/usr/bin/git). - Use explicit file‑access policies that treat redirections as file writes.
- Audit third‑party dependencies; OpenCode pulls ~10 k NPM packages, many of which are unreviewed.
- Consider alternative harnesses such as Pi.dev, Aider.chat, or a custom lightweight client that respects immutable prompts and offers deterministic session trees.
18. Conclusion
OpenCode’s current implementation suffers from systemic performance bottlenecks, unreliable permission handling, and a default remote‑first configuration that collectively expose users to data leakage and remote code execution. Until the project addresses prompt‑cache management, robust sandboxing, and secure default settings, developers should look for more mature AI coding agents or build a minimal harness that enforces strict OS‑level guardrails.
Sources
Related
- Dispatch
- Project
- Dispatch
- Dispatch