Bringing Claude Code into Neovim Developer Samarth developed claude-chat.nvim, a Neovim plugin that integrates Anthropic's Claude Code terminal UI directly into the editor, enabling editor-aware AI assistance without rebuilding existing features. The plugin uses MCP servers to sync editor state and LSP data, providing the same experience as VS Code and JetBrains extensions. I live in two places: a terminal running Claude Code https://www.anthropic.com/claude-code and Neovim. For months I bounced between them. Edit in Neovim, alt-tab to the terminal, paste a file path, ask Claude something, alt-tab back, apply the change by hand. The friction was small but constant, and constant friction is the kind that wears a groove in your day. The VS Code and JetBrains crowd already had the nice version of this: Claude living inside the editor, seeing the open file, the cursor, the selection, the diagnostics. Neovim didn’t. So I built it. It’s called claude-chat.nvim , and it’s 99.8% Lua. Here’s what it looks like in practice: /assets/img/claude-chat-nvim.gif The Claude Code TUI living in a Neovim sidebar, aware of the file I’m editing. The wrong way to build it My first instinct — same as with everything — was the heavy one. Wrap the Anthropic API. Manage my own conversation state. Re-implement streaming. Rebuild permission prompts. Build a little chat UI in a Neovim buffer and pipe tokens into it. That’s a lot of surface area, and every inch of it is something Claude Code already does and does better than I would. The moment I find myself re-implementing streaming or re-implementing a permission dialog, I’ve taken a wrong turn. The tool already owns those. So I threw the idea out and asked a smaller question: what if I didn’t wrap anything at all? Running the real thing Claude Code is a terminal UI. Neovim has terminal buffers. The whole plugin, at its core, is just: launch the actual claude CLI as a child process inside a Neovim terminal buffer, in a sidebar. That one decision pays for itself immediately. Because it is the real TUI, everything behaves exactly like running claude in a terminal — streaming replies, interactive permission prompts, session resume, all of it. I wrote zero code for any of those features. They came for free the instant I stopped trying to own them. This is the same lesson I keep relearning: the best version of a tool is usually the one that does the least , because it lets the existing pieces do their jobs. My job was connection, not reconstruction. The interesting part: making Neovim look like an IDE A terminal in a sidebar is convenient, but it isn’t the real prize. The real prize is editor awareness — Claude knowing what file I’m looking at, where my cursor is, what I’ve selected, what the LSP is complaining about. That’s what makes the VS Code experience feel magical instead of just colocated. It turns out Claude Code already knows how to talk to an editor. The VS Code and JetBrains extensions speak MCP https://modelcontextprotocol.io/ over a WebSocket, and the CLI knows how to dial back into that connection. I didn’t have to invent a protocol — I had to speak the one that already exists . So the plugin stands up two MCP servers, both bound to localhost with a per-session auth token: - A WebSocket MCP server speaking the same protocol Claude’s IDE extensions use, to sync editor state — open files, cursor, selection, diagnostics. - An HTTP MCP server hosting in-process tools like open file , current file , and bridges into Neovim’s LSP — definitions, references, hover, symbol search. The discovery handshake is the quietly satisfying bit. The plugin writes a lock file to ~/.claude/ide/