You fire up opencode serve, open your browser, and breathe a sigh of relief. Finally, a local AI coding assistant that keeps your code on your machine, away from the prying eyes of cloud providers. Except you’re not looking at a local web UI. You’re looking at app.opencode.ai, piped through your localhost port like a VPN to a server you never agreed to trust.
The discovery, recently detailed on r/LocalLLaMA, reveals that OpenCode’s web interface isn’t locally hosted at all. When you run the serve command, the binary creates a proxy that forwards nearly everything to OpenCode’s cloud infrastructure. Your “local” instance is essentially a tunnel to their servers, rendering the privacy benefits of local LLM usage moot.
The Proxy in the Machine
The technical implementation is brazenly simple. In the server code (around line 560 in server.ts), OpenCode implements a catch-all route that proxies requests to https://app.opencode.ai. There is no configuration flag to disable this. No --offline mode. No environment variable to point to a local build. Just a hardcoded URL funneling your traffic to their infrastructure.
This means when you load localhost:3000 (or whatever port), you’re not loading assets from your filesystem. You’re loading the web application from OpenCode’s servers, with your local process acting as a middleman. For developers working behind corporate firewalls, in air-gapped environments, or under strict data sovereignty requirements, this isn’t just an inconvenience, it’s a dealbreaker.
The distinction here matters. Transparent API integration versus hidden proxying represents the difference between informed consent and architectural sleight of hand. When you point Claude Code at a local llama.cpp instance, you know exactly where your data flows. With OpenCode’s web UI, the cloud dependency is invisible until you inspect the network traffic or read the source code.
The Title Generation Leak
If the proxy behavior wasn’t enough, the application also exhibited a particularly egregious data leak until recently. The TUI (Terminal User Interface) would upload your initial prompts to https://opencode.ai/zen/v1/responses to generate conversation titles, regardless of whether you were using a local model. The only way to prevent this was to explicitly disable the titling feature or configure a different small model.
While the maintainers have reportedly removed this fallback in recent versions, the pattern reveals a fundamental disregard for the security risks inherent in local AI execution environments. When users choose local execution, they’re not just optimizing for latency or cost, they’re making a security decision. Exfiltrating prompts to cloud servers for convenience features violates that trust boundary.
Community Patches vs. Corporate Silence
The community response has been swift and technical. Multiple pull requests attempt to solve this exact problem:
OPENCODE_APP_URL environment variable to allow custom web app hostingOPENCODE_WEB_URL to support local frontend serving with proper SPA fallbackThese aren’t cosmetic changes. One contributor, Chetic, verified PR #12829 in a fully air-gapped Docker container with --network none.
Against the current release, tests fail because the proxy can’t reach app.opencode.ai. Against the patched version, the embedded assets serve correctly from the binary itself.
Yet these PRs languish. Some have been open for weeks with no maintainer review, despite having working code and community support. This stagnation has fueled speculation about the project’s priorities. With significant VC backing, OpenCode has financial incentives that may not align with enabling fully offline usage, especially when they can monetize cloud-hosted features like their “Zen” service.
The refusal to merge basic transparency features (like displaying tokens-per-second metrics) while maintaining this cloud dependency suggests a product strategy that treats “open source” as a marketing label rather than an architectural commitment. This impact of corporate transparency on user trust and adoption isn’t theoretical, when users discover their “local” tool is phoning home, the backlash is immediate and severe.
The Architecture of Deception
The problem isn’t that OpenCode offers cloud features. It’s that the cloud dependency is the default, undocumented, and unavoidable for web UI users. The terminal interface might be local, but the web UI, arguably the more user-friendly and feature-rich interface, is essentially a SaaS product masquerading as local software.
For developers evaluating trade-offs between cloud costs and local inference, this architecture creates a false dichotomy.
You don’t actually get the benefits of local inference (privacy, offline capability, data control) if your interface layer is still cloud-dependent. It’s like installing a lock on your front door while leaving the back door wide open.
What Actually Works
If you need truly local AI coding assistance, the current state of OpenCode requires workarounds. Some users report success running the TUI in sandboxed environments with network blocking, though this breaks the web UI entirely. Others have forked the project to merge the community patches that enable local asset serving.
The examples of reliable local LLM implementations show that it doesn’t have to be this way. Tools like llama.cpp, Ollama, and various local frontends manage to serve their UIs from the filesystem without phoning home for static assets. The technical capability exists, the will to implement it appears to be the bottleneck.
Until OpenCode merges one of the community solutions or provides a built-in offline mode, the “local” claim comes with a massive asterisk. If you’re working with sensitive code, operating in restricted environments, or simply value the privacy that local AI promises, the web UI is currently unsuitable for production use.
The open source community has done the work to fix this. The question is whether OpenCode’s maintainers will let them, or if the cloud proxy is a feature, not a bug, of their business model.
