The terminal becomes the review surface
tuicr puts a GitHub-style continuous diff in a terminal, then adds the parts that plain git diff lacks: line and range comments, file-level notes, a review summary, and remembered progress. Vim keys drive navigation, search, file filtering, hunk movement, and visual selection. The result is aimed at someone who wants to inspect a change and write the review in the same interface, rather than bouncing between a pager, editor, and browser.
Three local version-control systems are supported: Git, Jujutsu, and Mercurial. The hosted side is broader than the opening README summary suggests. GitHub, GitLab, Bitbucket Cloud, and Azure DevOps each have submission instructions, while Markdown can go to the clipboard or stdout. Review sessions persist between launches, and reopening a previously reviewed pull request can preselect commits newer than the last submitted GitHub or GitLab review.
Inline submission depends on each forge's command-line client
The useful feature is real review submission rather than a block of notes you must re-enter elsewhere. GitHub can receive inline comments plus Comment, Approve, Request changes, or Draft outcomes. GitLab and Azure DevOps have their own supported action sets, while Bitbucket Cloud is limited to Comment or Approve. Azure builds the diff from a local clone because its API does not expose a unified diff.
That convenience has an operational price. GitHub needs an authenticated gh, GitLab needs glab, and Bitbucket needs bkt. Azure prefers a personal access token in AZURE_DEVOPS_EXT_PAT and falls back to az login. Self-hosted GitLab gets separate documentation. A reviewer moving among 4 forge backends must maintain those credentials and understand that capabilities differ. Bitbucket Data Center is explicitly outside the current scope.
What happened when we ran it
Our sandbox installed 295 packages in 29 seconds, and the Rust build completed successfully in 132 seconds. The checkout at commit 1723c9d contained 190 files, about 93,174 lines of source, and occupied 4.1 MB before dependencies. There were 3 CI workflow files and a tests directory, but no Dockerfile.
The test command failed with exit code 101 after 87 seconds. Across the reported run, 3,084 tests passed and 20 failed out of 3,104. The final library summary showed 1,542 passed, 10 failed, and 4 ignored, followed by Cargo's instruction to rerun the library tests. This is a substantial passing base, but the overall result is still red.
The log tail named Mercurial cases for commit-range diffs, recent commits, paths resembling pattern prefixes, Vue syntax context, NUL-delimited status paths, working-tree diffs, and whitespace handling. It did not include an error message that identifies why those cases failed. We will not assign the failure to missing packages or to tuicr itself without that evidence. Mercurial users should run the suite in their own environment before adopting it.
Large and unusual pull requests still expose gaps
Open issue 660 reports that selecting individual commits in a GitLab merge request can display an incomplete or wrong diff, while a direct local commit range works correctly in the reporter's sample. That is a sharp limitation for reviewers who inspect a series commit by commit. Issue 650 describes another PR-mode problem: .tuicrignore and path filtering happen after a large minified file has already gone through syntax highlighting, so the interface can stall before the exclusion helps.
Windows editor integration has a smaller but concrete rough edge. Issue 637 says $EDITOR=code fails because VS Code is launched through code.cmd on Windows and tuicr does not invoke a shell. Suggested-change comments are also requested in issue 542 rather than listed as supported. These are workflow-specific gaps, which is precisely why they belong in an adoption decision: each can remove the reason a team wanted a review TUI in the first place.
Configuration is deep enough for daily use
The config file covers side-by-side or unified diffs, whitespace handling, mouse input, relative line numbers, the leader key, comment editing, file exclusions, and local color themes. Reviewers can mark files or individual hunks as reviewed. A summary screen lists every pending draft comment and jumps back to its exact place without clearing reviewed state. Opening the focused file in $EDITOR is also built into the main key map.
Agent handoff is practical, though simple. Clipboard and stdout export produce numbered Markdown comments with file and line anchors. A bundled skill describes a split-pane workflow for coding agents, and the review-session CLI can list sessions, add comments, and print stored notes without opening the TUI. Export does not turn tuicr into an automated reviewer; it gives another tool a structured record of what a human or agent already found.
August activity is high, with 130 issues and pull requests open
GitHub recorded 2,967 stars, an MIT license, and 130 combined issues and pull requests when we fetched the project. The last push was August 29, 2026. Release v0.24.0 arrived on August 25 with fixes for editor resume behavior, Jujutsu diff parsing, reftable and bare-repository tests, and self-hosted GitLab detection. That combination shows active maintenance and a queue that is still moving.
tuicr earns a trial when code review is a keyboard task and direct forge submission matters. The 29-second install and successful build make that trial cheap, but our 20 failed tests stop us from calling the checkout clean. Start with the forge and version-control system you use most, exercise a real large pull request, and confirm that the submitted inline comments land on the lines you intended.