opencode.nvim: running an OpenCode agent in a Neovim side panel

A side panel with two buffers, because a prompt and a reply are different jobs

opencode.nvim is a Neovim frontend for OpenCode, a terminal-based AI coding agent. The core layout is a chat panel with separate input and output buffers. That separation is the design decision worth understanding before anything else, because it determines how you actually work. The input buffer is where you write, and the output buffer is where the agent replies, and you move between code and conversation rather than having a single scrolling pane that mixes your keystrokes with generated text. The panel also provides prompt history so a request you have sent before is a keystroke away rather than something you retype, and Markdown rendering so the agent's formatted replies read as formatted replies inside a terminal-familiar buffer. The screenshot in the repository shows the intended arrangement, an OpenCode chat panel sitting beside a code buffer rather than covering it.

Context is assembled by hand, which is the whole editorial position of the plugin

The context story is where this plugin differs from the usual agent-in-editor experience. You can send the current file, a visual selection, files mentioned with the @ key, diagnostics, and clipboard images. Note what is absent from that list: there is no mention of automatically handing the agent the whole project or an index of the repository. The agent sees what you decide it sees. That is a deliberate trade and it has two sides. The good side is that the agent does not wander into unrelated parts of a large codebase and the token budget stays on the thing you are working on. The cost is that a request needing broader context means you attach more, and a request needing to find the right file means you do the finding. For a reviewer who knows exactly which file and which function is broken, this is efficient. For a developer who wants to ask what a codebase does, it is manual work that the plugin will not do for you.

Multiple sessions get their own panel tabs, and the timeline can undo or fork

Sessions are the second structural feature. Multiple sessions are supported, each in its own panel tab, and there is a session picker alongside a timeline that shows the session tree and offers undo and fork. The practical value is that a long exploratory conversation and a small targeted edit do not have to live in the same history. You can keep the investigation open in one tab and start a focused change in another, then come back. Undo in this context is not just about reverting a diff, since the timeline sits alongside a session tree, which suggests the history is modelled as something you can move through and branch rather than a flat transcript. Forking in particular is the capability that matters when an agent goes down a path you do not want and you want to retry from an earlier point with different instructions rather than starting over from nothing.

Diff review turns inline comments into the next prompt, which is the part to try first

Session diff review is listed with inline comments that go into your next prompt, and the README marks this as requiring OpenCode V2. This is the most interesting loop in the plugin because it changes who writes the instruction. Instead of you describing the change you want and then discovering afterwards that the agent did something slightly wrong, you look at the diff the agent produced, leave a comment on the specific line that is wrong, and that comment becomes part of the request for the next round. The review is therefore not a separate step, it is the way you write the follow-up prompt. If you adopt this plugin for one feature only, adopt this one. The practical caveat is that it depends on the V2 server side, and the quick start lists the review keybinding separately from the send keybinding, which reflects that the two are gated on different server generations.

Quick chat handles a one-line edit without opening the panel

Quick chat is a separate mode for one-off edits on the current line or selection, and it is labelled experimental in the feature list. The scope is deliberately narrow and that narrowness is the point. Not every request deserves a full session with a panel tab, a timeline and a review cycle, and a rename of a variable or a change to a single argument is exactly the kind of thing where opening a side panel is more ceremony than the task deserves. Marking it experimental is the honest signal, because a mode that bypasses the session machinery may also inherit fewer of the context controls, and a quick edit that guesses wrong about which line you meant is worse than no quick edit. Try it on something disposable first.

Installing with lazy.nvim, and the two integrations you may want to change

The plugin needs Neovim 0.10.3 or later and the opencode CLI on your PATH, with a provider already connected by running opencode and using /connect. With lazy.nvim the configuration looks like this:

return {
  'sudo-tee/opencode.nvim',
  dependencies = {
    {
      'MeanderingProgrammer/render-markdown.nvim',
      opts = {
        anti_conceal = { enabled = false },
        file_types = { 'markdown', 'opencode_output' },
      },
      ft = { 'markdown', 'opencode_output' },
    },
  },
  opts = {},
}

The upstream snippet comments out several optional integrations so you can pick what matches your setup: a picker such as folke/snacks.nvim, nvim-telescope/telescope.nvim, ibhagwan/fzf-lua or nvim-mini/mini.pick, or the built-in vim.ui.select, and a completion engine such as saghen/blink.cmp or hrsh7th/nvim-cmp, or the built-in completion. The render-markdown.nvim dependency is the one that is not optional in that snippet, because it is what makes the output buffer readable. With any other plugin manager you install the plugin and call require('opencode').setup({}), then run :checkhealth opencode, which is the first thing to run when something is not working.

Four keys and a prompt, which is the entire quick start

The quick start is four steps. Open a file and press the leader key sequence oi, which opens the prompt in insert mode. Type a request, and the README gives a realistic example, Add a test for the empty-list case. Press Esc and then CR to send. And on V2, press the leader sequence od to review what the agent changed. The order matters and is worth internalising: Esc leaves insert mode so you can read what you wrote, and CR then sends it, which means a mis-typed prompt is caught before it leaves. That is a small design choice with a real payoff, because an agent request sent by accident can mean an unwanted edit to a buffer. The getting started page covers the same steps in more detail and adds pickers and completion. Inside Neovim, the built-in help is searchable with :help opencode.nvim.

V1 and V2 both work, but the v1 branch is a separate history

The plugin works with OpenCode V1 and V2 servers, and the protocol is detected automatically, so you do not pick a mode yourself. The v1 branch keeps the old plugin code and is not needed for a V1 server, which is a slightly confusing sentence that means the compatibility is handled in the current code for a V1 server, and the branch exists mainly for anyone who needs the older plugin itself. There is a Compatibility document for the details, and a Servers document for connecting to something other than the default. The project is based on goose.nvim by azorng, and the original code was copied rather than forked so that its Git history is preserved, which is the kind of decision that helps anyone reading the diff between the two projects later. The repository also carries AGENTS.md, a Makefile with type checking, formatting and replay test targets, and a tests directory.

Editorial conclusion

opencode.nvim suits a Neovim user who wants to drive OpenCode without leaving the editor and who prefers assembling context explicitly rather than letting the agent guess what it can see, and the inline comment review loop is the part worth adopting even if you never touch the rest. It does not suit someone who wants a fully autonomous mode where the agent scans the project on its own, because context here is something you attach deliberately. Before you rely on it, run :checkhealth opencode after installing, confirm your OpenCode CLI is on PATH with a provider already connected through /connect, and read the compatibility notes, since the plugin handles V1 and V2 servers by detecting the protocol and the v1 branch exists for the older one.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. sudo-tee/opencode.nvim on GitHub