give the agent some active neovim abilities and one-shot non-interactive edits

[ferdinandyb]

Tldr; I'm proposing two things: a small opencode plugin to open up better interaction for the agent with neovim (most notably: and taking a little bit of inspiration from 99.

Problem

I'm currently trying to regain more control and clarity over agentic code. My current setup is opencode.nvim (opencode running in a floaterm, and I'm trying to force myself to never open opencode outside nvim), 99 and a up until very recently a neovim mcp, which I have ditched for a skill, that explains how to use the --remote-expr to do some things with neovim. Running opencode inside neovim is actually great for opencode->neovim interactions, because the socket path is trivially available.

I generally use opencode.nvim as talking with the agent is of course very valuable and the plugin is great in sending in context etc. There are two things I use 99 for: one is the one-shot background exploration agent which you ask a question and loads the resulting places it finds into the quickfix list and the one where you visual select an area and it rewrites that area (has a fun indicator too that it's happening), which is also a one-shot one, so it's very focused and much closer to you writing a small bit of code with a very fancy autocomplete. I like that you can do some parallel work that doesn't get into your "main" agents context, and has a visual indicator that it's happening in the background.

But I have several gripes with this setup also:

• the 99 exploration agent cannot be given context about where you're at in a file, so you can't go "pull up all places where @this pattern is used in the codebase"
• the 99 quickfix list goes through a weird hoop of writing a temp file to disk and then using that file to load the quickfix
• the neovim mcp was super invasive, the agent would try and go about mutating neovim state all over and trying to bypass write permissions by editing in neovim or sending in commands while I was doing something else
• my new --remote-expr solution is also terrible for security, since it's basically an arbitrary code execution path for the agent, so I'm forced to accept prompts every time
• any time the main opencode instance opened by opencode.nvim is running, the only way to know that is to bring it up to be visible

Proposal

companion plugin in opencode

Add a small companion opencode plugin, which provides neovim tool(s) for opencode. Should be probably gated behind the existence of $NVIM or something like that, so it only pollutes context when it makes sense. Since it's a plugin for opencode it will naturally be opt-in for user. The most important capability would be to load entries into the quickfix list and to provide a replacement mechanism for given marks in nvim (for the edit this, and just this selection). Some other things it could do: read cursor position, visual selection position, buffer list etc. I think the only writing capability should really be the quickfix list, which is innocent enough usually, and is a very natural place to put info in vim.

better background support in opencode.nvim

This is two parts:
a) add support for one-shot non-interactive agent invocations that either rewrite a very specific area only (so no it's not the agent's edit tool doing the edits, because that can go all over, but very specifically to a controlled area) or searches where the input is not the entire main agent session, just a simple prompt then and there with some cursor/selection position info and the output is just the quickfix list and
b) if either a one-shot agent is running or the main opencode instance is running, but is not actually visible show a "running" indicator (I'm not sure detecting visibility is trivial with so many way to connect to an instance, so maybe it could be always there if something is running, opt-in obviously).

Notes

Obviously the quickfix list tool makes sense in the main agent as well for more interactive things, while the "edit this specific area" is not usable this way since since the marks in neovim won't be set for it. Also, with 99 I've seen that for the background agents you need to make a special non-visible agent in opencode that has edit, bash, tasks and todowrite disabled to make them work.

What do you think, could these be in scope for opencode.nvim?

[nickjvandyke]

Thanks for your ideas!

load entries into the quickfix list

I agree this is neat and I'm working on it already, but with an IMO better, simpler implementation. The plugin listens for file-related events from OpenCode (atm file.edited and read tool calls) and then adds the corresponding file to the quickfix list. I pushed that to the quickfix-events branch just now if you care to try. There seems to be a bug in parsing the file read events, but otherwise it's working well for me. One disappointment is that OpenCode doesn't include the line numbers in the edit event though.

I like the one-shot idea and have toyed with it before. Ultimately I decided against it. It's too specific and requires lots of code. opencode.nvim focuses on bridging Neovim and the OpenCode TUI for simplicity and familiarity. Background prompting is an entirely different code path and would scope-creep into re-implementing lots of TUI stuff. Not to mention whatever it'd take to restrict OpenCode to editing a specific area.

You might be able to compose opencode.nvim APIs to create one-shot-like behavior though. Create a new session, send your prompt to it (optionally including @<subagent>), then select the previous session. Assuming OpenCode continues processing backgrounded sessions.

So I think these are neat ideas but imo they fit better outside opencode.nvim 🙂

[ferdinandyb]

Thanks for your ideas!

Thanks for the quick response!

load entries into the quickfix list

I agree this is neat and I'm working on it already, but with an IMO better, simpler implementation. The plugin listens for file-related events from OpenCode (atm file.edited and read tool calls) and then adds the corresponding file to the quickfix list. I pushed that to the quickfix-events branch just now if you care to try. There seems to be a bug in parsing the file read events, but otherwise it's working well for me. One disappointment is that OpenCode doesn't include the line numbers in the edit event though.

Would this mean that the quickfix list is being constantly appended with changes happening? Are you planning configurability for what events are included in this quickfix push? E.g. a read event sounds very noisy, it might not even be important, but edits are probably something you'd always want.

It also sounds like something that could/should be fixed in opencode (i.e. opencode not emitting line numbers). I'm not sure how hard it is to get a PR into OpenCode, but you probably have some prestige there to get it in :)

Anyhow, I'll take a look at the branch tomorrow.

I like the one-shot idea and have toyed with it before. Ultimately I decided against it. It's too specific and requires lots of code. opencode.nvim focuses on bridging Neovim and the OpenCode TUI for simplicity and familiarity. Background prompting is an entirely different code path and would scope-creep into re-implementing lots of TUI stuff. Not to mention whatever it'd take to restrict OpenCode to editing a specific area.

That's a reasonable limit to put on the scope of opencode.nvim

You might be able to compose opencode.nvim APIs to create one-shot-like behavior though. Create a new session, send your prompt to it (optionally including @<subagent>), then select the previous session. Assuming OpenCode continues processing backgrounded sessions.

Ack, I'll take a look if it would be easier to build on top of opencode.nvim (or get back to 99 and see if some of my issues can be fixed there).

One last thing, which you didn't react to: how about an optional "OpenCode is doing something" indicator somewhere?

[nickjvandyke]

Would this mean that the quickfix list is being constantly appended with changes happening? Are you planning configurability for what events are included in this quickfix push? E.g. a read event sounds very noisy, it might not even be important, but edits are probably something you'd always want.

It only appends files that aren't already in the list, so IME it shouldn't grow that big. I would like to allow event configuration, just not sure what schema I want yet; I plan to merge it without configuration and see how it feels. Edits are also navigable via git tools, whereas this would be the only way to conveniently view what OpenCode has viewed.

It also sounds like something that could/should be fixed in opencode (i.e. opencode not emitting line numbers). I'm not sure how hard it is to get a PR into OpenCode, but you probably have some prestige there to get it in :)

Agreed. I try to stick to the Neovim side of things for my sanity but would gladly add support to the plugin if someone else PR'd that to OpenCode.

One last thing, which you didn't react to: how about an optional "OpenCode is doing something" indicator somewhere?

Check the lualine section in https://github.com/nickjvandyke/opencode.nvim#integrations 🙂