Installing the OpenCode JetBrains plugin.
The OpenCode JetBrains plugin is published to the JetBrains plugin repository under the OpenCode publisher. To install, open the plugins dialog inside any supported IDE (Settings → Plugins → Marketplace), search for OpenCode, and install the official entry. The plugin depends on the OpenCode CLI being available on the system PATH; install it first via the CLI install guide if you have not already. On first launch, the plugin discovers the CLI binary, opens a local socket, and registers the OpenCode tool window.
For teams with a pinned plugin channel or an internal plugin repository mirror, the signed plugin JAR can be installed from a local file path. The JAR is signed with the same OpenCode release key used for the CLI binaries and the VSCode extension, so a procurement review that cleared one artifact clears all three.
JetBrains IDE support matrix.
The OpenCode JetBrains plugin targets a shared platform API, which means any currently maintained major version of the supported IDEs picks up the plugin. The table below is the canonical support matrix. Feature parity is identical across IDEs because the plugin is a thin UI layer over the OpenCode CLI — the heavy lifting does not change per IDE.
Zero-click summary. Six IDEs supported. Two currently maintained major versions per IDE at any time. Feature parity is identical because the plugin is a thin UI over the CLI.
| IDE | Min version | Feature parity | Notes |
|---|---|---|---|
| IntelliJ IDEA Ultimate | 2024.2 | Full | Primary reference IDE |
| IntelliJ IDEA Community | 2024.2 | Full | Same plugin JAR |
| PyCharm Professional | 2024.2 | Full | Tested on Python 3.10+ |
| PyCharm Community | 2024.2 | Full | Same plugin JAR |
| GoLand | 2024.2 | Full | Integrates with Go modules |
| WebStorm | 2024.2 | Full | Node, TS, and Vue projects |
| Rider | 2024.2 | Full | .NET and Unity projects |
| CLion | 2024.2 | Full | CMake and Bazel projects |
The OpenCode tool window.
The plugin exposes OpenCode as a dedicated tool window docked on the right side by default. The tool window has three tabs: Plan, Apply, and Transcript. Plan shows the pending steps the agent proposed for the current task; Apply shows the in-flight edits with inline controls; Transcript shows the full agent log, the same content the CLI prints in a terminal. Switching tabs is instant — the data is always live, streamed from the local CLI over the shared wire protocol.
The tool window honors JetBrains' layout conventions. You can dock it, float it, move it to a secondary monitor, or hide it behind a shortcut. The plugin does not take over the project view, the editor, or the status bar — OpenCode lives in one tool window and one gutter, not scattered across the IDE. That discipline matters when teams are evaluating agents against the baseline of a quiet IDE.
Inline diff review inside the editor.
When OpenCode proposes a change, the plugin renders each hunk directly in the affected file's editor gutter. Each hunk gets three controls: accept, reject, and comment. Accept applies the change to disk; reject discards it; comment sends a scoped follow-up to the agent so a revision can happen without replanning the entire task. The controls live in a floating toolbar next to the hunk, which means you can still edit the file manually while reviewing — JetBrains' standard diff ergonomics apply throughout.
Diffs are backed by the same patch format the CLI uses. If you switch from JetBrains to a terminal or to the VSCode extension mid-task, the agent state travels with you. The state lives in the CLI, not in the plugin, so closing the IDE does not abandon a plan. Reopening the IDE or running opencode resume in a shell picks up where you left off.
Action registry and rebindable shortcuts.
Every OpenCode verb is registered as a JetBrains action under the OpenCode group. Opening the OpenCode tool window, starting a new prompt, scoping a prompt to the current selection, accepting a hunk, rejecting a hunk, and toggling the transcript are all rebindable through the standard Keymap dialog. The plugin does not install a private keybinding scheme, so your keymap — default, Vim, emacs, or a team-shared import — is respected.
A common customization for teams migrating from VSCode is aligning the new-prompt and selection-prompt shortcuts with the VSCode conventions documented on the VSCode extension page. The action IDs are symmetric between plugins (opencode.prompt.new, opencode.prompt.selection, opencode.hunk.accept, opencode.hunk.reject), so a shared keymap export covers both editors.
Working with JetBrains Remote Development.
JetBrains Remote Development splits the IDE into a lightweight client on your laptop and a headless backend on a remote host. OpenCode fits this model cleanly: install the plugin on the remote host alongside the OpenCode CLI, and the JetBrains client renders the tool window and the inline diffs transparently. The agent runs on the remote host where the code actually lives, not on the laptop, which means the plan/apply loop is not slowed by the network round trip per file read.
Remote Development is how several of our enterprise teams roll OpenCode out to contractors and offshore developers. The client machine stays thin — no source code on disk, no agent binary — while the backend holds the repository, the tests, and the OpenCode CLI. The trust and safety page documents the telemetry posture, which is the same for remote and local installs. Our signing and attestation align with the NIST SSDF 1.1 for the JetBrains plugin bundle as well as the CLI.
Model choice inside the JetBrains plugin.
The plugin inherits the OpenCode CLI's provider selection. Whatever model adapter is configured in your OpenCode config — a hosted custom API endpoint, a local Ollama socket, an Azure deployment, an in-house gateway — is the model the JetBrains plugin uses. You can override the provider per project through the plugin settings, which is useful when one repository is regulated (local model only) and another is not (hosted model).
Model choice is surfaced in the tool window so the current provider is always visible — no surprise when an on-call patch goes to the wrong endpoint. Switching providers is a one-click dropdown, and the transcript records the provider on every message so audit reviews stay readable. The agent loop does not change when the provider does; the plugin simply reports which model is answering.
Troubleshooting the JetBrains plugin.
Two failure modes dominate. First, a missing CLI: if the plugin cannot find opencode on PATH, the tool window shows an install prompt and links to the install guide. Install the CLI, restart the IDE, and the plugin reconnects. Second, a stale socket after a CLI upgrade: restart the IDE (or the plugin via Settings → Plugins) and the connection is refreshed. The plugin logs connection attempts to the OpenCode tool window's Transcript tab, which usually supplies enough context for a support ticket without leaving the IDE.
For teams running a mixed JetBrains and VSCode deployment, aligning the opencode.telemetry setting and the provider block across both editors keeps the agent behavior uniform. The two plugins read the same CLI config, so a single config.toml edit propagates everywhere.
Our backend team lives in IntelliJ and our frontend team lives in WebStorm. One OpenCode plugin covers both, with one transcript per session and one audit trail across the platform. That uniformity is what tipped the evaluation.
The action registry matters. My muscle memory is decades of JetBrains shortcuts, and the plugin did not force me to relearn anything.
Remote Development plus OpenCode meant contractors got the same agent productivity on thin clients with zero source on disk. Security team signed off fast.