The OpenCode extension model.
Every OpenCode extension is a thin UI layer over the local OpenCode CLI. The extension opens a local socket, exchanges a session token, and then streams plan and apply events back and forth. The heavy work — reading files, running tests, talking to models — happens inside the CLI, not inside the extension. That design has two practical outcomes: extensions stay small (a few hundred kilobytes, not hundreds of megabytes), and the agent behavior is identical across editors because the same binary drives every surface.
Because the CLI is the canonical surface, every workflow you can describe in the terminal also works from every editor extension. That includes queuing multiple tasks, pausing a plan, resuming a session, and auditing a tool call log. When we say "one agent, many surfaces," the wire protocol is what makes that claim concrete. A team running mixed editors ends up with one audit trail, not six.
Editor feature parity.
The table below is the canonical parity matrix for OpenCode editor extensions. Inline diffs and selection prompts are the minimum bar for every certified entry. Plan mode — the ability to preview a multi-step plan before any edit lands — ships in the editors where the UX is natural, and is planned for the rest.
Zero-click summary. Six editors supported. Inline diffs and selection prompts everywhere. Plan mode in VSCode, JetBrains, and Neovim today. Rest are on the roadmap.
| Editor | Inline diffs | Selection prompts | Plan mode | Status |
|---|---|---|---|---|
| Visual Studio Code | Yes | Yes | Yes | Official |
| JetBrains IDEs | Yes | Yes | Yes | Official |
| Neovim | Yes | Yes | Yes | Community certified |
| Helix | Yes | Yes | Roadmap | Community certified |
| Zed | Yes | Yes | Roadmap | Community certified |
| Sublime Text | Yes | Yes | Roadmap | Community certified |
Official OpenCode extensions.
Two extensions sit in the official tier, which means the OpenCode maintainers build, sign, test, and release them on the same cadence as the CLI. An official extension passes the integration test suite before every release, ships with a signed manifest that matches the CLI signing key, and carries a maintenance SLA documented in the trust and safety page.
OpenCode VSCode extension.
The OpenCode VSCode extension is the flagship editor integration. It adds a side panel, inline diff review, selection-scoped prompts, a status-bar transcript, and a full shortcut map covering every CLI verb. Install from the Visual Studio Code marketplace or from a signed VSIX on the download page for air-gapped workstations.
OpenCode JetBrains plugin.
The OpenCode JetBrains plugin covers IntelliJ IDEA, PyCharm, GoLand, WebStorm, Rider, and CLion. It exposes OpenCode as a tool window with plan/apply controls, an action registry for rebindable shortcuts, and the same inline diff ergonomics as the VSCode build. Install from the JetBrains plugin repository inside any supported IDE.
Community-certified OpenCode extensions.
Community certification is what keeps the extension hub useful without forcing the core team to maintain every editor. A community-certified extension has a named maintainer, passes the integration test suite, and ships a signed release manifest that can be verified against the published OpenCode signing keys. The core team tracks the certification status per release so a regression in the test suite flags a certification review.
Neovim extension.
The OpenCode Neovim extension is a Lua plugin installable from any modern Neovim plugin manager. It uses the Neovim quickfix list for diffs, the command-line interface for prompts, and a scratch buffer for the transcript. Plan mode lands in the telescope picker so multi-step plans feel like normal Neovim navigation. Keybindings follow the standard <leader>o prefix convention and are fully rebindable.
Helix extension.
The Helix integration is a short config snippet plus a companion binary that speaks the OpenCode wire protocol and surfaces plan/apply controls through the Helix picker UI. Inline diffs use the Helix selection mode so a proposed hunk is visible without leaving the primary split. The extension is small enough to audit in an afternoon.
Zed extension.
The Zed integration registers OpenCode as an extension in the Zed extensions registry and exposes actions through the Zed command palette. Diffs use the Zed multi-buffer view so multi-file changes stay legible. The extension picks up Zed's collaboration mode so pair-programming sessions see the same OpenCode transcript.
Sublime Text extension.
The Sublime Text integration installs through Package Control and exposes OpenCode via the command palette and an output panel that mirrors the status-bar transcript from the VSCode extension. Inline diffs use Sublime's phantom API for non-intrusive overlays on the buffer.
How certification works.
Maintainers of a community extension submit an integration test report, a signed release manifest, and a maintenance commitment. The OpenCode core team runs the integration tests on a reference workstation for each supported editor version, then admits the extension to the certified tier. Certification is per-release, not perpetual: an extension that fails the tests on a future CLI release drops back to the preview tier until the maintainer ships a fix.
The certification process is documented so any downstream distributor — a Linux distro maintainer, a corporate procurement team, a university IT group — can audit the chain. For teams in regulated industries the certification trail pairs with the guidance from the code.gov portal and broader OSS procurement advice in the US Energy Department open-source policy. Our release discipline is informed by research from MIT CSAIL on signed software distribution.
Zero-click summary. Certification is per-release. Maintainers submit tests plus a signed manifest. Failing tests drop an extension back to preview.
Maintainer ownership and triage paths.
Every OpenCode extension page on the hub links to its upstream maintainer repository. The split of responsibility is predictable: bugs in the agent or the wire protocol are triaged by the OpenCode core team; bugs in editor-specific UI belong to the extension maintainer. In practice that split covers every case we have seen, and the hub carries cross-references so a reporter lands on the right tracker on the first try.
Extension maintainers receive advance notice of wire protocol changes through the OpenCode release candidate channel. Breaking protocol changes are rare, and when they happen the core team works with every certified extension maintainer to land a compatible release before the CLI ships. That coordination is why the parity table changes slowly — the point of certification is stability, not novelty.
Picking an OpenCode extension for your team.
Most teams do not have to pick. The OpenCode extension hub is designed so each engineer installs the plugin that matches the editor they already use, and the platform team gets a single audit trail regardless of which editors appear on the developer workstations. That is the point of a wire-protocol-first design: the agent does not care which editor drove it, and neither does the compliance review.
If you are starting fresh and want the deepest feature set today, the VSCode extension is the most feature-complete. If your team is standardized on JetBrains IDEs, the JetBrains plugin exposes the same capabilities in a native tool window. For terminal-centric engineers the CLI alone is usually enough, with a light Neovim or Helix wrapper for inline diffs when the edit is bigger than a one-liner.
I run Helix, my teammate runs VSCode, our platform engineer lives in Neovim. Three editors, one OpenCode transcript, one audit trail. That's the story I couldn't tell with the last agent we tried.
The Sublime extension is not the flashiest, but it fits my editor's conventions. That matters more than feature parity headlines.
Certification gave our procurement team the provenance trail they needed. Signed manifests on every OpenCode extension, checked against one published key.