agentic.nvim puts ACP agent sessions in a Neovim chat sidebar

A protocol boundary rather than an agent implementation

agentic.nvim is described as a chat interface for AI agents in Neovim that works with any provider supporting the Agent Client Protocol. The plugin list names Claude, Gemini, Codex, OpenCode, Cursor Agent, Copilot, Auggie, Mistral Vibe, Cline, Goose, Kiro and Pi, and the README is explicit that the list is not exhaustive, because any provider implementing the protocol works.

That framing decides most of the design questions. The plugin does not embed a model, does not manage API keys, and does not implement its own tool calling. It speaks a protocol to a provider that already exists on your machine, and the provider's own CLI does the thinking.

The README's own summary is the clearest statement of intent: Agentic.nvim is the interface, your agent is the Brain. It also promises the same results and performance as using the provider's official CLI directly from the terminal, and states that there are no hidden prompts or magic happening behind the scenes, just a chat interface, your colors and your keymaps.

That last claim is the one to test when you adopt it. If the plugin were injecting its own system prompt to shape behaviour, the equivalence would not hold, and the model would behave differently inside Neovim than in your terminal. The design decision is that the plugin is a renderer and a transport, and nothing else.

The primary language is Lua, which is what a Neovim plugin is written in, and the repository layout follows the standard plugin shape with a lua directory holding the source, plus tests, docs, a doc directory, a Makefile and CI workflows.

Zero config authentication because the provider already logged in

The authentication story is the feature that removes the usual friction of adding an agent to an editor.

The README describes zero config authentication with no API keys needed, and explains the mechanism: run claude /login, or gemini auth login, once, and if they are working on your terminal, they will work automatically on Agentic. The framing is that your credentials live with the provider, and the plugin does not need its own copy.

That is a real architectural choice with a real consequence. Because the plugin inherits the provider's session rather than creating one, it also inherits the provider's failure modes. If a provider requires an interactive browser flow for authentication, the plugin cannot do that for you, and a headless or remote environment where the provider is not yet logged in is a case the plugin does not solve.

The same reuse applies to everything else the provider carries. The README says that including your MCP servers, commands, SKILLs and sub-agents, you do not have to recreate your configuration to use Agentic.nvim. For a user who has spent time wiring MCP servers into a terminal agent, that is the single most valuable line in the document, because the alternative is maintaining two configurations that drift apart.

Sessions follow the same logic. The README says sessions are interchangeable: start a conversation in Neovim and continue it in the terminal, or pick up a terminal session inside Neovim, and that the ACP provider manages sessions natively so they are available everywhere. The plugin is not keeping its own transcript; it is asking the provider for one.

The sidebar, permissions and the file picker

The interface is a sidebar with markdown rendering and syntax highlighting, and the feature list describes the interaction model in enough detail to judge whether it fits your workflow.

Context is added with one keypress: files and text selections can be added to the conversation context. Images can be dragged and dropped or pasted directly into the chat, which covers screenshots. A file picker is triggered by typing @, with native completion for workspace files and support for referencing multiple files in one message, for example @file1.lua @file2.lua.

Slash commands use Neovim's own completion, with fuzzy filtering, and every slash command the provider exposes appears when you type / as the first character in the prompt. That last detail is what makes the plugin feel like an interface rather than a wrapper, because the command set comes from the provider rather than from a hardcoded list.

The permission system is worth reading closely, because it is where an agent plugin can be dangerous. The README describes an interactive approval workflow for AI tool calls that mimics Claude-code's approach, with 1, 2, 3 and so on as one-key press responses. So a tool call does not execute silently; it appears and waits for you. A model with shell access is only as safe as that prompt, and this one is explicit rather than implicit.

Agent mode switching is on Shift-Tab and moves between ACP-supported modes such as Default, Auto Accept and Plan mode, depending on what the provider offers. And a model switcher on <localLeader>m and a provider switcher on <localLeader>s both work mid-session, with the provider switch preserving chat history.

Multiple sessions that keep running when hidden

The multiple session support is the part that separates this plugin from a simple chat buffer, and the README describes the behaviour precisely.

You can run as many independent chat sessions as you like, simultaneously, on different tasks. The important detail is what happens when you are not looking: a session keeps working while hidden, closing its window or its tab does not stop it, and any session can be brought up in any tab.

That is a different model from an embedded terminal, where closing the window usually ends the process. It is closer to how a long running agent job should behave, where the work continues while you switch to another task in the editor.

The cost of that model is that a session is a live process, not a transcript, and the plugin is therefore managing several provider processes concurrently. If you run five sessions with a heavy agent, you are running five agents, and the resource usage and the tool permission prompts multiply accordingly. The README does not document any limit on concurrent sessions, so the practical limit is whatever your machine and your provider tolerate.

The README also mentions Smart Context, which automatically includes system and project information in the conversation. The README stops the description there, so the exact scope of what Smart Context includes is worth checking in the source before relying on it, since automatic context injection is exactly the kind of behaviour that changes what the model sees.

Running the test suite and the tooling around it

The README does not give an installation command for the plugin itself. The repository follows the standard Neovim layout with a lua directory, so it is loaded as a plugin by the plugin manager you already use, and the documentation directory plus the doc folder hold the user facing notes.

What the README does document is the development tooling, and the repository ships a Makefile with a full set of checks, which tells you something about how the project is developed.

The test target runs Neovim headless against a test harness:

	$(NVIM) --headless -i NONE -n -u tests/init.lua -c "lua require('tests.runner').run()"

A separate target runs a single file, which is the usual shape for a plugin with many small units. The rest of the Makefile is a static analysis pipeline: a Lua Language Server headless diagnosis report over the lua and tests directories, using a project .luarc.json, with a check that fails if VIMRUNTIME cannot be determined, a Selene linter, and StyLua for formatting with both a check mode and an apply mode. The tool paths are all overridable through environment-style variables such as NVIM, LUALS, SELENE and STYLUA, with a fallback to a Mason installation path.

There is a target called rules that runs a shell script under scripts, and the comment above it describes what it enforces: mechanical AGENTS.md rules covering banned calls, asserts in deferred callbacks, and a committed rules report, with a self-test that proves each check still fires. A self-test for the lint rules is an unusual and good practice, because a lint script that silently stops matching is worse than no lint script.

The configuration files are visible in the repository: a .stylua.toml for formatting, a selene.toml for the linter, a .luarc.json for the language server, a vim.toml, an AGENTS.md and a CONTEXT.md, plus .agents and .claude directories, which suggests the project itself is developed with the same kind of agent tooling it provides an interface for.

Where this plugin does not help, and what to check first

The boundaries follow from the architecture rather than from missing features.

The first is that you need an ACP provider. The plugin is a client for the protocol, so a Neovim user with no agent installed has nothing to connect to, and the plugin will not supply a model or an account. This is a deliberate division of labour, but it means the setup cost of the plugin is really the setup cost of the provider.

The second is that the plugin does not make the agent more capable, and the README is honest enough to say the results are the same as using the provider's CLI directly. If your workflow depends on a specific prompt engineering technique, a custom tool, or a provider feature that only exists in the terminal client, you may find the plugin falls short of the terminal experience. The claim of equivalence also depends on the provider exposing the same capabilities over ACP as it does locally, which varies between providers.

The third is the dependency on the provider's session model. Because sessions are provider-native, anything that changes the provider's session handling changes your experience in Neovim, and there is no local fallback if a provider's ACP mode regresses.

On maintenance, the repository is not archived and the last push was on 2026-10-16, so the code is being changed, but there are no GitHub releases, which means you install from the default branch and there is no tagged version to pin. The licence is MIT, with a LICENSE.txt at the repository root.

If you are weighing this against simply using the provider's own CLI inside a Neovim terminal split, the difference in approach is that the plugin speaks the protocol rather than embedding a terminal, so it gets native completion, a structured permission prompt and session portability, at the cost of depending on the provider's ACP implementation being complete.

Editorial conclusion

Adopt agentic.nvim if you already run an ACP agent from the terminal and want the same session inside Neovim without rebuilding your configuration, since the plugin reuses your existing provider setup, MCP servers, commands, skills and sub-agents rather than asking you to configure them twice. Do not adopt it if you have no ACP provider installed, because the plugin is the interface and the provider does the work, and do not expect it to change what your agent can do, since the README states you get the same results as using the provider's official CLI directly. Verify first that the provider you use exposes an ACP mode, that the authentication you rely on works headlessly rather than only through an interactive terminal login, and that the keymaps the README mentions, such as the model switcher on <localLeader>m and the provider switcher on <localLeader>s, do not collide with the ones you already have.

Frequently asked questions

Official sources

1. carlos-algms/agentic.nvim on GitHub
2. Issues
3. License: MIT
4. README