# codediff.nvim: a review workspace for changes that keep arriving

> codediff.nvim is a Lua plugin for Neovim that turns the editor into a live code review surface, with VSCode style side-by-side and inline diffs, staging controls, branch and pull request review, and merge conflict resolution, aimed at workflows where a coding agent edits the repository while a human watches. It ships a native diff library that the plugin downloads for you.

**esmuellert/codediff.nvim** — Live code review for Neovim with VSCode style diffs

- Repository: https://github.com/esmuellert/codediff.nvim
- Stars: 1,606 · Forks: 102
- Language: Lua
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/esmuellert-codediff-nvim

## Review as a workspace, not a set of commands

The plugin's tagline is a statement of intent: keep the agent running, review changes as they land. CodeDiff is described as a live code review workspace for Neovim with VSCode style diffs, built for human-in-the-loop AI development. That framing explains a design choice that would otherwise look odd. A conventional diff workflow in Neovim involves a series of separate commands, one buffer at a time, and the mental load of remembering which stage of the review you are at. CodeDiff instead presents the pending changes as a workspace you navigate, with the diff, the file list, the staging controls and the conflict view in one place. The feature list names the pieces: live review where changes appear as they land while a coding agent works in the background, VSCode style diffs with line and character level highlighting, human control over staging, unstaging and discarding files and hunks, complete workflows covering local changes, staged changes, revisions, pull requests and history, focused navigation between files and hunks with folding of unchanged code and tracking of moved blocks, conflict resolution per block or across a whole file, and Tree-sitter syntax highlighting kept in revision buffers. The last of those is the detail that shows the care taken: a diff buffer that loses syntax colouring is hard to read.

## The native diff library, and why the download step exists

Underneath the Lua plugin sits a native library, and the repository makes that clear with a libvscode-diff/ directory at the top level and a CMakeLists.txt at the root. The library is what produces the character-level highlighting, and the plugin is designed so that you never build it. The documentation states plainly that no compiler is required, because the plugin automatically downloads pre-built binaries from GitHub releases, on first use and after plugin updates. The binaries are named by platform, with libvscode_diff.so or libvscode_diff_<version>.so on Linux and BSD, libvscode_diff.dylib or the versioned equivalent on macOS, and libvscode_diff.dll on Windows, and they go in the plugin root directory. There is a Linux wrinkle worth knowing: if libgomp.so.1 is not available to Neovim, the release also ships libgomp_linux_{arch}_{version}.so.1, which you download for the same architecture and rename to libgomp.so.1 in the plugin root. The library can also be built from source, which needs a C11 compiler, with CMake 3.15 or newer optional for the developer build. The Makefile in the repository is a wrapper around CMake and is described as auto-generated, and the same file says users should use build.sh instead since it does not require CMake.

## Installing through lazy.nvim, or by hand

With a plugin manager the whole configuration is three lines, because the plugin registers a single command:

```lua
{
  "esmuellert/codediff.nvim",
  cmd = "CodeDiff",
}
```

The cmd key means Neovim only loads the plugin when you run the :CodeDiff command, which keeps startup fast. The prerequisites are modest: Neovim 0.7 or newer with 0.10 or newer recommended, Git for the repository workflows, curl or wget on Unix or PowerShell on Windows for the automatic downloads, and optionally a Nerd Font for the default Explorer folder icons. If you want the library installed up front or need to repair it, there are two commands:

```vim
" Install or update the diff library
:CodeDiff install

" Force reinstall
:CodeDiff install!
```

Without a plugin manager, the route is a clone plus a runtime path line. The clone goes to a local directory:

```bash
git clone https://github.com/esmuellert/codediff.nvim ~/.local/share/nvim/codediff.nvim
```

and init.lua appends that path to the runtime path:

```lua
vim.opt.rtp:append("~/.local/share/nvim/codediff.nvim")
```

The diff library is still fetched on first use in that setup, so the manual route is only about the plugin itself.

## The configuration is where the plugin shows its opinions

The configuration reference is long and specific, which is a good sign for a plugin aimed at people who will tune it. Highlights are configurable at two levels, with line_insert and line_delete taking highlight group names or hex colours, and character level equivalents that override a brightness calculation when set. The brightness multiplier is auto-derived from the background when left nil, at 1.4 for dark and 0.92 for light, so the character shading adapts to the colourscheme without configuration. Conflict signs have their own four-way scheme, unresolved, resolved, accepted and rejected, each with a documented fallback chain, which is unusual care for something that is essentially a highlight group name. The diff behaviour options are where the design shows. The layout is side-by-side or inline, with inline using virtual lines, and a filler_text pattern aligns the two panes, with an empty string for blank alignment rows. max_computation_time_ms defaults to 5000, which the documentation notes is the VSCode default, so a pathological diff cannot hang the editor. ignore_trim_whitespace and hide_merge_artifacts control whether whitespace-only changes and merge tool temporary files such as *.orig and *.BACKUP.* are shown, and original_position, conflict_ours_position, conflict_result_position and conflict_result_height decide where the old content, the ours side of a conflict and the result pane are placed.

## Where codediff.nvim is the wrong tool

The scope is the limitation. This is a local review surface for a working tree, not a pull request review service. The feature list includes reviewing pull requests and history, but the plugin runs on your checkout and its actions are staging, unstaging and discarding, so the audit trail, the comments, the approvals and the required reviewers of a hosted review system are not what it provides. The second limit is the native dependency. Although there is no compiler requirement in the normal path, the plugin needs a platform-specific shared library that it fetches over the network on first use, which is a problem on an air-gapped or heavily restricted machine, and the manual route then involves downloading a binary from a release page and renaming it to one of several expected filenames. A third point is the Neovim version spread. The plugin supports 0.7 and newer but recommends 0.10 or newer, so on an older Neovim you are on the compatibility path rather than the recommended one, and the diff library binaries are version-matched to the plugin. There is also a plain product question: if you are not already living in Neovim, installing a plugin to review diffs is a large detour next to a web UI.

## How this differs from reviewing in a browser

The alternative is the hosted pull request interface, and the difference in approach is where the review happens. A browser review puts the diff on a server, with the repository copied there, and the reviewer works against a rendering that was designed for reading long conversations about code rather than for editing a local working tree. CodeDiff keeps the repository where it is and makes the editor the review surface, which is the point for a workflow where the changes are still landing, where the reviewer may want to stage or discard hunks as they arrive, and where the work continues in the same buffers afterwards. The cost is that a browser review is available to anyone with a link, including people who do not have Neovim, and it keeps a history of the discussion that a local workspace does not. The two are closer to complementary than competing: a local workspace for the moment of change, a hosted review for the record of the decision. The plugin's own feature list, which mentions staging, discarding, pull requests and history in the same breath, is an attempt to cover both, and the tree shows the effort, with a doc/ and docs/ directory, an AGENTS.md, a .stylua.toml for Lua formatting, a .clang-format for the C side, a tests/ directory with both C and Lua test targets, and a Makefile whose test target runs ctest for the C library and a shell script for the Lua side.

## Conclusion

Adopt codediff.nvim if you run Neovim and your review work arrives in bursts, whether from a coding agent or a colleague, and you want one surface for inspecting, staging and discarding changes without leaving the editor. Do not adopt it as a replacement for a hosted pull request review, because the review it provides is local to your working tree and its scope is the diff and the conflict. Before you install, check that your Neovim is 0.7 or newer with 0.10 recommended, that Git is available, and note that the plugin downloads a prebuilt native diff library on first use, so a locked-down environment needs the manual binary placement route.

## FAQ

### What is codediff.nvim and what is it for?

It is a Neovim plugin that provides a live code review workspace with VSCode style diffs, built for human-in-the-loop AI development. You can inspect, stage, unstage or discard files and hunks, review branches and pull requests, browse history, and resolve merge conflicts from the same workspace.

### Do I need a compiler to install codediff.nvim?

No. The plugin automatically downloads matching pre-built binaries from GitHub releases on first use and after plugin updates. Building the diff library from source instead needs a C11 compiler, with CMake 3.15 or newer optional.

### How do I install codediff.nvim with lazy.nvim?

Add the plugin with the cmd set to CodeDiff, so it loads only when the command runs: `{ "esmuellert/codediff.nvim", cmd = "CodeDiff" }`. The `:CodeDiff install` command installs or updates the diff library, and `:CodeDiff install!` forces a reinstall.

### What are the prerequisites for codediff.nvim?

Neovim 0.7 or newer with 0.10 or newer recommended, Git for the repository workflows, curl or wget on Unix or PowerShell on Windows for the automatic downloads, and optionally a Nerd Font for the default Explorer folder icons.

### What licence is codediff.nvim released under?

The project is licensed under the MIT License, with the LICENSE file at the repository root. The latest release is v4.0.6 from 2026-09-15, which is also the date of the last push.

## Sources

- [esmuellert/codediff.nvim on GitHub](https://github.com/esmuellert/codediff.nvim)
- [Issues](https://github.com/esmuellert/codediff.nvim/issues)
- [License: MIT](https://github.com/esmuellert/codediff.nvim/blob/main/LICENSE)
- [README](https://github.com/esmuellert/codediff.nvim/blob/main/README.md)
- [Releases](https://github.com/esmuellert/codediff.nvim/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/esmuellert-codediff-nvim