OpenCode VSCode: install, configure, and drive the agent from your editor.

Installing the OpenCode VSCode extension from the marketplace.

The OpenCode VSCode extension is published on the Visual Studio Code marketplace under the OpenCode publisher account. To install it, open the extensions view in VSCode, search for OpenCode, and pick the entry whose publisher is listed as the OpenCode project. The extension depends on the OpenCode CLI being on your PATH, so install the CLI first via the CLI install guide if you have not already. When the extension starts, it discovers the CLI binary, opens a local Unix domain socket on macOS and Linux or a named pipe on Windows, and shows the OpenCode panel in the activity bar.

For air-gapped or policy-restricted workstations, the extension also ships as a VSIX bundle from the OpenCode download page. Drag the VSIX into VSCode or install with the code --install-extension command. The signature on the VSIX matches the key used to sign the CLI binaries, so endpoint management teams can verify both artifacts from the same attestation. The integrations registry links to the signing manifest for every official OpenCode extension.

Zero-click summary. Install the CLI first. Install the extension from the marketplace or a signed VSIX. Both artifacts share one signing key.

The VSCode shortcut map.

OpenCode ships a default keybinding scheme that avoids clashes with the VSCode built-in bindings. All commands are listed under the OpenCode category in the keybindings editor, so rebinding a shortcut is a normal VSCode workflow — the extension does not install a private keybinding file that would be overwritten on upgrade. The table below is the canonical shortcut map.

Zero-click summary. Six primary actions, each with a macOS and a Windows/Linux binding. Every binding is rebindable in the VSCode keybindings editor.

Using the inline diff panel.

The OpenCode VSCode extension renders every proposed edit as an inline diff over the active file. Each hunk has three controls: accept, reject, and comment. Accepting a hunk applies that change to disk; rejecting discards it; commenting sends a follow-up instruction to the agent scoped to that hunk so the agent can revise without replanning the entire task. The hunks are not modal — you can keep typing in the file while deciding, and the extension rebases the diff as you edit.

Diffs are backed by the same patch format the CLI uses in the terminal, which means you can switch from VSCode to a shell session mid-task and keep going. The agent state lives in the CLI, not in the extension, so closing VSCode does not abandon a plan. Reopen VSCode or run opencode resume in a terminal and the transcript picks up where you left off.

Selection-scoped prompts.

Highlight a range, press the selection-prompt shortcut, and type an instruction. OpenCode pins the selection as the target range so the agent does not wander into unrelated files. This is the shortcut most engineers use the most — it feels like talking to the code in front of you instead of describing a task across the whole repo. The agent still has read access to the rest of the repository through the tool call layer, but writes are scoped unless you explicitly broaden them.

Status-bar transcript.

The status-bar transcript is a compact log of the last tool call, the last plan step, and the current agent state. It is useful for reviewing what the agent did while you were focused on a diff in another file. Clicking the transcript opens the full scrollable log in the side panel. The status bar updates in real time, so long-running tool calls — test runs, dependency installs — stay visible without stealing keyboard focus.

Settings.json reference for the OpenCode VSCode extension.

The extension reads a short list of keys from settings.json. The two most useful are opencode.model (pin a specific model for VSCode sessions, overriding the CLI default) and opencode.telemetry (set to off to disable both VSCode-level and CLI-level telemetry for this workspace). Other keys cover the socket path, the diff font, and the transcript buffer size. Settings apply per-workspace and per-user, following the standard VSCode precedence rules.

When a team wants a shared config — say, a pinned internal model name and a disabled telemetry flag — the usual pattern is a .vscode/settings.json committed at the repository root. Every engineer who opens the repo picks up the same OpenCode defaults without any onboarding doc. For workstation-wide defaults, set the same keys in the user settings, and per-repo settings will override them where needed.

Teams running regulated workloads typically pair the telemetry opt-out with the guidance in the NIST supply-chain risk management program when reviewing third-party editor extensions. Our signing process for the OpenCode VSCode extension aligns with those recommendations.

Disabling telemetry and running offline.

OpenCode ships telemetry off by default. The extension respects both the VSCode telemetry setting and the dedicated opencode.telemetry key. When both are off, neither the extension nor the CLI makes any outbound HTTP request beyond the configured model endpoint. For fully offline workflows, pair the extension with the Ollama adapter so the model endpoint itself is a local socket, and nothing the extension sees leaves the machine.

For enterprise deployments, the extension supports a pinned update channel through the VSCode enterprise extension gallery, so the IT team can stage OpenCode releases after a security review. The signing key and SBOM for every release are published next to the VSIX, making audit diligence straightforward.

Keybinding customization: the honest version.

VSCode keybindings can conflict with language extensions, Vim mode, emacs mode, and your personal preferences. OpenCode follows the VSCode convention: all commands are exposed by ID, all bindings are visible in the keybindings editor, and nothing is injected at runtime. If you run Vim mode, the selection-prompt shortcut Cmd+K Cmd+L does not conflict with a leader sequence, but you can rebind it to whatever <leader>oc feels natural. The shortcut map above is the defaults, not the contract.

A common customization for JetBrains refugees is rebinding the new-prompt action to a chord that matches the JetBrains muscle memory. That works out of the box — the command is opencode.prompt.new and any binding syntax VSCode supports will pick it up. When we refer to the OpenCode JetBrains plugin, we use the same command IDs so a team running mixed editors gets a predictable naming scheme.

Troubleshooting the VSCode extension.

The most common failure is a missing CLI. If the extension cannot find the OpenCode binary on PATH, the status bar shows a red dot and the side panel displays an install prompt. Install the CLI via the CLI install guide, reload the VSCode window, and the extension re-connects. For Windows users on ARM64, make sure the installer picked the matching architecture from the Windows page.

The second most common failure is a stale socket. If you upgraded the CLI while VSCode was running, the extension may be talking to an older socket. Reload the VSCode window or restart the extension host and the connection is re-established. The extension logs every connection attempt to the OpenCode output channel so a reproduction for a support ticket is usually one copy-paste from the output pane.

Related OpenCode editor guides.