opencode.nvim: Bringing OpenCode AI Assistance Into Neovim Without Leaving Your Editor

The Problem opencode.nvim Solves

OpenCode is an AI coding assistant with its own terminal user interface. Using it in a standard workflow means switching to a separate terminal window or pane, pasting code, describing context, and then copying changes back into your editor. That round-trip interrupts the editing flow that Neovim users have typically optimised.

opencode.nvim eliminates the manual context copying. It connects to an OpenCode server, which can either be running separately or started as an integrated instance from within Neovim. It reads cursor position, selections, buffer contents, diagnostics, and quickfix lists, and sends them to OpenCode as structured context through placeholder tokens. Changes that OpenCode proposes come back as edits that can be accepted or rejected from Neovim without leaving the buffer.

The plugin's stated philosophy, from the README, is that AI works best as a pair programmer at small, focused scopes with the human driving. The plugin provides the interface for that model while keeping the user in their existing environment, config, and keybindings.

The core design decision is to use OpenCode's existing TUI and API rather than replicating them inside Neovim. This means opencode.nvim does not ship its own chat pane or model configuration UI. What it does provide is a clean bridge: a way to inject editor state into OpenCode conversations and a way to act on OpenCode's output directly in the buffer. For users already running OpenCode, this is a natural extension of their existing workflow. For users who have not adopted OpenCode, the dependency is the primary trade-off to evaluate.

Context Injection: What opencode.nvim Sends to OpenCode

The plugin replaces placeholders in prompts with live editor state before sending them to OpenCode. The available placeholders are documented in the README:

- @this: the current selection or range, or the cursor position if nothing is selected - @buffer: the contents of the current buffer - @buffers: all open buffers - @diagnostics: LSP diagnostics within the selection, or in the current buffer if nothing is selected - @marks: global marks - @quickfix: the quickfix list - @visible: the visible text in the current window

This means a prompt like "Explain @this" will include the selected code automatically. The README notes a practical constraint: OpenCode reads referenced files from disk, so unsaved buffer changes must be written before sending context that depends on the file's state.

The built-in prompt library covers common tasks. The README lists prompts for reviewing, explaining, and improving code. Custom prompts with the same placeholder syntax can be added through the configuration.

The @diagnostics placeholder is particularly useful in a debugging workflow. If the current buffer has LSP errors or warnings, sending @diagnostics to OpenCode with a prompt like "What is causing @diagnostics?" sends the actual error messages along with their locations, without requiring manual copy-paste. The @quickfix placeholder works the same way for errors captured in the Neovim quickfix list, which is populated by tools like grep, compile output redirects, or make.

The OpenCode events integration is listed in the features section of the README as well. These are handled as Neovim autocmds, which means other plugins and configuration can react to OpenCode events through the standard Neovim event system without additional hooks.

Installation and First Setup

The plugin supports three installation methods. The README recommends vim.pack, which is Neovim's built-in package manager:

vim.pack.add({
  {
    src = "https://github.com/nickjvandyke/opencode.nvim",
    -- Defaults to "main", supporting OpenCode v2.
    -- Uncomment to pull the latest stable release, supporting OpenCode v1.
    -- version = vim.version.range("*"),
  },
})

---@type opencode.Opts
vim.g.opencode_opts = {
  -- Your configuration, if any; goto definition on the type for details
}

-- Recommended/example keymaps
vim.keymap.set({ "n", "x" }, "<C-a>",   function() require("opencode").ask("@this: ") end,                    { desc = "Ask OpenCode…" })

For lazy.nvim, the spec uses "nickjvandyke/opencode.nvim" as the plugin identifier with the same vim.g.opencode_opts configuration table. For nixvim, the plugin is available as pkgs.vimPlugins.opencode-nvim.

The README recommends running :checkhealth opencode after setup to verify the connection. All available configuration options and their defaults are in lua/opencode/config.lua, which the README points to for a goto-definition lookup.

The default keymaps the README suggests are C-a for Ask (normal and visual modes) and C-x for a second action. These are example mappings, not enforced defaults; the configuration table in vim.g.opencode_opts controls everything, and users who already use C-a for something else should remap. The plugin's design principle, stated in the README, is that it provides simple, sensible, Vim-y defaults, meaning it tries to fit into existing Neovim conventions rather than imposing a new interaction pattern.

Integrations with snacks.nvim, blink.cmp, and lualine

The plugin is designed to work alongside other popular Neovim plugins. The README documents several optional integrations.

snacks.input enhances the Ask prompt interface with snacks' input UI. snacks.picker lets you browse and select files, diagnostics, or other items and send selected items to OpenCode via a custom opencode_send action.

snacks.terminal can be used to run the OpenCode server in a Neovim terminal pane, configured via the server.start callback in vim.g.opencode_opts. The example in the README uses snacks.terminal to open OpenCode on the right side without entering the pane.

blink.cmp is configured to provide LSP-based completions from opencode.nvim's in-process language server inside the Ask prompt buffer. This applies when snacks.input is also enabled.

lualine.nvim can show the currently connected OpenCode server and its status in the status line:

require("lualine").setup({
  sections = {
    lualine_z = {
      {
        require("opencode").statusline,
      },
    },
  },
})

None of these integrations are required. The plugin works without any of them.

How opencode.nvim Compares to codecompanion.nvim and avante.nvim

codecompanion.nvim and avante.nvim are both Neovim AI plugins that operate differently from opencode.nvim. They communicate directly with LLM APIs (OpenAI, Anthropic, and others) using API keys configured inside Neovim, without a separately running server or TUI. The AI interaction happens through Neovim buffer-based interfaces: a chat buffer in codecompanion.nvim, a sidebar in avante.nvim.

opencode.nvim's architecture is different in a fundamental way: it delegates to OpenCode. OpenCode handles the API communication, the conversation history, and the model selection. Neovim is the front-end for context injection and edit acceptance. This means opencode.nvim's feature set is bounded by what OpenCode exposes through its TUI and API.

The advantage of the opencode.nvim approach is that it inherits OpenCode's multi-model support and configuration without duplicating it. The limitation is that it requires OpenCode to be installed and running, which adds a dependency that codecompanion.nvim and avante.nvim do not have.

Sidekick is another alternative mentioned in the search data for this plugin. Like avante.nvim, it aims to provide AI assistance within the editor environment without an external dependency, though the README does not describe its architecture directly.

The comparison that matters most is not which plugin has more features but which model of interaction fits the user's workflow. Developers who think of the AI as an integrated chat interface inside the editor tend to prefer codecompanion.nvim or avante.nvim. Developers who already run OpenCode in a terminal and want to stop copying code between windows will find opencode.nvim a direct solution to that specific friction.

Users who prefer not to run an external server process will be better served by the alternatives. Users already invested in OpenCode's configuration and workflow will find opencode.nvim a tighter integration than context-copying by hand.

Maintenance and Licence

The last push to the repository was on 2026-09-24. Releases v1.0.0 (2026-08-20), v1.0.1 (2026-09-11), and v1.0.2 (2026-09-14) are published on GitHub. The main branch targets OpenCode v2; v1.0.2 is the latest stable release for OpenCode v1. The versioning distinction matters: if your OpenCode installation is on v1, setting version = vim.version.range("*") in the plugin spec pins to the latest stable release and avoids pulling the v2-targeting main branch prematurely.

The plugin is MIT-licensed. The repository includes a CHANGELOG.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md. An AGENTS.md file is also present in the top level, which documents guidance for AI-assisted contributions to the plugin itself.

The three patch releases within the first month of v1.0.0 suggest active maintenance at the time of the last documented push. The repository is not archived. There are no open-source guarantees about the future release cadence, but the presence of CHANGELOG.md with documented changes across releases provides a reliable upgrade path for users tracking new versions.

Editorial conclusion

opencode.nvim is the right plugin if you use OpenCode as your AI coding assistant and want to stay in Neovim rather than switching to a terminal or separate application. The context injection system, prompt library, and edit accept/reject flow are well-designed for the pair-programmer model. It is a poor fit for users who want a fully integrated AI chat pane inside Neovim without depending on an external OpenCode process, or those who prefer an AI assistant without a terminal UI. Alternatives like codecompanion.nvim and avante.nvim provide AI assistance directly inside Neovim using API keys, without a separately running OpenCode server. Check the README's compatibility note: the main branch targets OpenCode v2, while version = "*" in the plugin spec pins to v1.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nickjvandyke/opencode.nvim on GitHub
4. README
5. Releases