Claude Code in Neovim: Setup and a Reviewable Workflow
You can run Claude Code alongside Neovim in a terminal split and review every edit before accepting it. Here is how to set up the workflow, supply repository context, and keep a shared task brief in fenbs.
Updated 5 min read
Claude Code runs as a terminal process, which makes it a natural companion to Neovim. You open Claude Code in a terminal split or a separate pane, give it access to your repository, and review its edits in your normal editor workflow before accepting any change. Nothing in this setup requires a plugin; it works with the Claude Code CLI and whatever terminal emulator you use.
A task brief that lives outside the session means both tools are working from the same information. Tools like fenbs keep the task, its requirements, and Where we left off in a shared record that Claude Code can read at the start of each session.
How do you open Claude Code alongside Neovim?
The simplest approach is a terminal multiplexer. With tmux, you can split the window into panes: one for Neovim, one for Claude Code, and one for a shell. Claude Code runs in the shell pane, reads and writes files in your project directory, and you review changes in the Neovim pane.
tmux new-session -s dev tmux split-window -h # Pane 1: nvim . # Pane 2: claude
If you prefer an integrated terminal, Neovim's built-in terminal emulator (:terminal or :term) opens a terminal buffer inside the editor. You can run Claude Code there and switch between the terminal buffer and your file buffers with normal Neovim navigation. The editor and Claude Code then share the same working directory automatically.
A community plugin for Claude Code in Neovim also exists and may offer additional conveniences such as opening Claude Code in a dedicated pane with a keybinding. Check the plugin's repository for compatibility with your current Claude Code version before relying on it for important work.
How do you supply repository context to Claude Code?
Claude Code reads CLAUDE.md files starting from the directory where you run it. Place a CLAUDE.md at the project root with the information Claude Code needs: the project structure, which directories are off-limits, the build command, how to run tests, and any standing decisions about the codebase.
Keep CLAUDE.md focused on facts that change how Claude Code should act. It is not a README or a general project description. If a rule appears in both CLAUDE.md and fenbs Decisions and rules, the versions must agree; a discrepancy will confuse a future session.
How do you review Claude Code's edits in Neovim?
Claude Code writes changes directly to disk. After each file edit, reload the buffer in Neovim (:edit or :checktime) and read the diff before continuing. If you use a Git-integrated plugin such as gitsigns or vim-fugitive, you can see the hunk-level diff inline as you review.
Do not rely on Claude Code's description of its changes. Read the actual diff. The description and the diff can disagree when a change has side effects the session did not anticipate. Confirming each change against the task criteria is faster than debugging a hidden change after the fact.
How do you keep changes focused on the current task?
Give Claude Code a precise, bounded instruction rather than a broad goal. "Add an empty state to the file list component at src/components/FileList.tsx" is a better starting point than "improve the file list." A precise instruction produces a diff you can evaluate against clear criteria.
If Claude Code modifies a file outside the stated scope, correct it before continuing. Ask it to revert the unintended change and explain why the scope was exceeded. Recording the scope boundary in the CLAUDE.md or the fenbs task plan prevents the same overreach in the next session. A clear boundary is also faster to verify when you read the diff.
How do you hand off to another session?
Save the task state before closing either Neovim or the Claude Code session. Where we left off in fenbs records which files were changed, what was verified, and what the next step is. A future session, whether from the same machine or a different one, can read that record and continue without a long explanation.
Keep the task brief outside the terminal session
Add the task requirements and current constraints to fenbs before starting. Ask Claude Code to read the project context at the beginning of the session. Before stopping, save task progress and Where we left off. The next Neovim session, on any machine, starts from the same shared record.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account and add the project you are working on in Neovim.
- Connect Claude Code to fenbs from Integrations. Keep the terminal with Claude Code and the fenbs browser tab open side by side if needed.
- At the start of each session, ask Claude Code to read the project context from fenbs. Confirm it can state the current task and any standing rules correctly before giving it the first instruction.
- Review each diff in Neovim before telling Claude Code to continue. Note any scope violations in the fenbs task as they occur.
- Before stopping, ask Claude Code to save progress and Where we left off to fenbs. Record any decisions made during the session.
fenbs does not integrate with Neovim directly and does not know which files are open. It holds the task record that Claude Code reads and updates. For understanding Claude Code's session history and resume options, the Claude Code history guide explains how past sessions are stored. For running Claude Code in a sandboxed environment to test risky changes, the sandbox guide covers the setup.