The OpenCode platform, end to end.

How the OpenCode platform is put together.

The OpenCode platform is built around a single statement: the agent is a local process, and every surface is a client. That means when you run OpenCode in a terminal, the agent process spins up in the current working directory. When you open the OpenCode desktop app, the same agent process spins up behind a native window. When you attach the OpenCode VSCode extension, the extension host launches the same agent as a child process. The protocol between the agent and its clients is a documented JSON-over-stdio stream with a small set of verbs: plan, apply, observe, revert, log.

That architecture is what lets OpenCode stay boring and inspectable. You can pipe the same agent behind a bash script on a CI runner, behind a GUI on a developer laptop, or behind a browser on a tablet that cannot install binaries. The tools the agent calls — read-file, write-file, run-shell, run-test — are identical across surfaces, so the security posture a platform team approves on the CLI is the exact posture every other surface inherits.

Why the CLI is canonical.

Treating the CLI as the source of truth means OpenCode has exactly one authoritative binary to ship, sign, reproduce, and audit. Every other surface is a layer.

Editor extensions and the desktop app do not re-implement planning or tool execution. They spawn the OpenCode agent process and stream structured events from it. If the CLI fixes a bug, every client on every surface picks up that fix on the next run. If a security policy forbids a tool, the CLI enforces it and no client can bypass the block.

How clients negotiate with the agent.

Clients and the agent exchange a compact JSON envelope on stdio. The first message is a capability handshake: client advertises what it can render (diffs, plan trees, approval prompts), agent advertises what it can run (file tools, shell tools, test harness hooks). A quiet handshake lets a minimal client render text-only output while a rich client shows inline diffs.

The envelope is forward-compatible. New verbs added to a later CLI will be ignored by older clients, and clients can opt into newer rendering modes without forcing the agent to change. This is why the VSCode extension can ship on a faster cadence than the CLI without drift, and why the web console can be redeployed without coordinating a CLI release.

Supported operating systems and runtime footprint.

The OpenCode platform runs where developers actually work. The CLI is a static binary with zero runtime requirements beyond a working libc on Linux.

On macOS, the CLI is a universal binary that covers Intel and Apple silicon in one file. The desktop app is an arm64 binary for Apple silicon machines and a universal binary download is available for mixed fleets. On Windows, the CLI ships as an x64 and an arm64 binary, and the desktop app is distributed as an MSI installer with a corresponding winget manifest. On Linux, the CLI is a static x86_64 and aarch64 binary that works on glibc 2.28 or newer, plus a musl static variant for Alpine-based containers and build images.

Platform lifecycle policy.

Stable releases ship every six weeks. LTS releases ship once a year with eighteen months of security patches. A nightly channel is published daily for early adopters.

Every release is signed with a pinned key, published with a CycloneDX SBOM, and accompanied by an SLSA level 3 build attestation. Downstream distributors — Homebrew, winget, apt repositories, container registries — can verify each artifact against the transparency log before republishing. Deprecation notices land in the changelog one LTS cycle before removal, so teams running on the LTS branch never encounter a surprise breaking change mid-cycle.

Licensing, governance, and procurement fit.

OpenCode is a permissive open-source project governed by a small maintainer council with a published charter. Contributors sign a DCO; the LICENSE is a one-page permissive text reviewed by outside counsel.

OpenCode has a published security disclosure policy on the trust and safety page, a coordinated disclosure channel, and a public incident history in the changelog. Release engineering follows NIST SSDF 1.1 controls for build isolation and artifact signing, with independent review sourced where appropriate through code.gov referrals. Procurement packets — control mappings, SBOMs, attestations — are refreshed every quarter and attached to the LTS tag.

How procurement teams evaluate OpenCode.

Security architects treat an AI coding agent the same as any other build-time tool: signed binaries, reproducible builds, SBOMs, and a documented update channel.

OpenCode satisfies those controls out of the box. The SBOM is CycloneDX 1.5, the build attestation is SLSA level 3, the binaries are signed with a Sigstore-rooted key, and the transparency log is public. Endpoint management teams can pin a single version across the fleet or track LTS with a predictable window. A sample procurement packet — legal, security, and operational — is available on the trust and safety page.

How teams adopt the OpenCode platform.

Platform adoption in practice follows a three-step pattern. One engineer installs the CLI, proves a workflow, and presents the transcript to the team.

Step two is adding the VSCode or JetBrains extension for teammates who prefer a GUI. Because the extensions spawn the same CLI, nothing new has to be approved by the security team — the same binary that was already vetted is the same binary under the editor. Step three is rolling the desktop app or the web console to reviewers and team leads who want an approval queue or a read-only audit surface without installing yet another tool. At that point, the entire team — writers, reviewers, auditors — share a single platform with a single security model.