tuicr: a vim-native code review TUI that pushes inline comments to five forges

What tuicr solves and who it is for

tuicr addresses a specific pain: code review that happens in a terminal, with the ability to write inline comments and then push them as a real review to a forge. The README positions it as a TUI with vim keybindings, which immediately targets developers who already use vim or modal editors. It is for people who review pull requests, merge requests, or plain diffs without leaving their terminal, and who need the review to land back on GitHub, GitLab, Bitbucket, or Azure DevOps. The tool also supports git, jj, and mercurial, which is a broader VCS range than most review tools. The intended user is likely a backend or infrastructure engineer who spends hours in a terminal and finds the GitHub web review interface too slow or too mouse-dependent. The README's comparison table shows that tuicr is the only tool listed that pushes inline comments to all three major forges, which is the core differentiator.

The mechanism: continuous diff, modal comments, and export pipeline

The core mechanism is a continuous diff stream. Instead of viewing files one by one, tuicr scrolls through every changed file in a single stream, styled after GitHub's diff view. You navigate with j and k, press c to add a comment at the line, range, file, or review level, and then either copy the review with y or submit it with :submit. The review is tracked at file or hunk granularity and persisted across sessions, so you can close the TUI and resume later. The export pipeline is the key architecture: comments are stored locally as pending drafts, and :submit opens a picker for the review action (Comment, Approve, Request changes, or Draft, depending on the forge). For each forge, tuicr uses the corresponding CLI (gh, glab, bkt, or az) to post the inline comments. For Azure DevOps, there is no unified-diff API, so tuicr builds the diff locally with git diff base...head, which means you must run tuicr from a local clone. The clipboard export produces a structured markdown block with numbered comments and file/line anchors, designed for pasting into a coding agent.

Getting it running: install commands and first launch

Installation is straightforward and offers multiple paths. The README lists a curl script, Homebrew, pacman, cargo, mise, and nix. The quickest path is curl -fsSL tuicr.dev/install.sh | sh, or brew install tuicr on macOS. For a source build, you clone the repo and run cargo install --path . from the root. The first launch is tuicr, which opens a commit selector; you can also run tuicr tui for the same TUI explicitly, tuicr -w for uncommitted changes, tuicr -r main..HEAD for a commit range, or tuicr pr 125 for a GitHub or Bitbucket PR. For GitLab, use tuicr mr 125. The update mechanism is notable: tuicr update checks which package manager owns the executable and uses that manager to upgrade, with SHA-256 verification for script-installed binaries. This is a practical touch for a tool that will likely be installed on many machines.

Export targets and their real constraints

The export targets are the heart of tuicr, but each has its own limitations. GitHub requires gh authenticated to the repo, and :submit offers Comment, Approve, Request changes, or Draft. GitLab requires glab authenticated to the host, and Request changes only works if your account is an assigned reviewer. Bitbucket requires bkt authenticated to bitbucket.org, and only Comment and Approve are supported; Draft and Request changes are not, and Bitbucket Data Center is explicitly out of scope. Azure DevOps uses a Personal Access Token in AZURE_DEVOPS_EXT_PAT, with a fallback to az login, and requires running tuicr from a local clone because there is no unified-diff API. The clipboard export is the most flexible: y or :clip copies a markdown block that can be pasted into any coding agent. The README even describes an agent-driven workflow where the agent opens tuicr in a split pane, which suggests the tool is designed to fit into AI-assisted development loops.

The vim model and the review tracking trade-off

tuicr's vim keybindings are not just j/k navigation; the README mentions visual mode, {N}G, and Ctrl-d/Ctrl-u, which are core vim motions. This is a deeper modal model than a tool like lumen, which only has j/k navigation. The trade-off is that if you do not know vim, the learning curve is steep. The review tracking is another trade-off: tuicr persists reviewed state at file or hunk granularity, and when you reopen a PR, it preselects commits newer than your latest submitted review, marking already-covered commits with a checkmark. But this only works when the forge records which commit an approval covered. Bitbucket does not, so that preselection does not apply there. This is a genuine limitation: if you review a Bitbucket PR, you lose the convenience of automatic commit-level progress tracking.

The :summary view and the limits of a TUI

The :summary command shows every pending local-draft comment in a list that replaces the diff, with the file sidebar still visible if open. You can navigate with j/k, press Enter to jump to a comment in the continuous diff, and Esc to return. The first comment is selected automatically, and the view scrolls to keep it visible. This is a well-thought-out feature for managing multiple comments, but it also reveals a limitation: the TUI is single-pane, so you cannot see the diff and the summary at the same time, unless you open the sidebar. The README says the summary replaces the diff, which means you lose context while reviewing the list. For a tool that prides itself on a continuous diff, this is a design compromise. It is not a fatal flaw, but it is a place where a split-pane layout would be more ergonomic.

Alternatives and the actual difference in approach

The README compares tuicr to hunk, lumen, gh pr review, and git diff. The key difference is that hunk and lumen are TUI diff viewers that let you write comments, but they do not push inline comments to any forge. gh pr review can post a review, but only at the review level, not inline line comments. git diff is just a diff viewer. So tuicr's approach is to be a full review lifecycle tool: you view the diff, write comments, and submit them as a real PR review, all in the terminal. The alternative that comes closest is hunk, which is also a TUI diff viewer with comment support, but it lacks vim keybindings and forge export. If you only need to view and comment locally, hunk might be simpler. But if you need to push the review back to GitHub or GitLab, tuicr is the only one in this comparison that does it.

Maintenance, license, and upgrade cost

tuicr is written in Rust and released under the MIT license, which is permissive and suitable for commercial use. The project is actively maintained, with recent releases in August 2026, including v0.24.0. The update mechanism is built in, which reduces maintenance cost: tuicr update handles upgrades through the package manager that owns the executable, or in-place for script-installed binaries with SHA-256 verification. This is a strong point for keeping the tool current. The upgrade cost is low because the tool is a single static binary, so there are no dependencies to manage. However, the license does not include any warranty, and as with any tool that interacts with forge APIs, you should verify that the CLI tools (gh, glab, bkt, az) are installed and authenticated, as these are external dependencies. The README points to specific docs for GitLab and Bitbucket setup, which suggests that configuration is not always trivial.

Editorial conclusion

Adopt tuicr if you live in a terminal, use vim keybindings, and review code across git, jj, or mercurial with a need to push inline comments to GitHub, GitLab, Bitbucket, or Azure DevOps without leaving the TUI. Skip it if you prefer a graphical review interface, rarely leave the GitHub web UI, or need Bitbucket Data Center support, which is explicitly out of scope. Before adopting, verify that your forge's CLI (gh, glab, bkt, or az) is authenticated and that your repo is a local clone, since Azure DevOps requires a local git diff. Also check the docs for Bitbucket token scopes and GitLab self-hosted setup, as these are the areas with the most setup friction. The project is actively maintained with regular releases, and the single static binary makes installation trivial, but the real cost is learning the modal keybindings and accepting that Bitbucket approval does not track commit coverage, so preselecting newer commits will not work there.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes