Crit: a local review UI that sends your comments back to the coding agent

The gap Crit fills between an agent's output and your judgement

An agent writing a plan and an agent changing a handler look identical to the model: both are text. The README states the problem directly, that for agents plans and code are the same, while reviewing a generated plan and reviewing a running web application are two different activities for a human. Crit's answer is to pick a rendering mode from the argument you pass it, so the review surface matches the artifact.

The audience is narrow and specific. You need an agent that can read a file and run a command, because that is the contract the whole loop depends on. The README lists Claude Code, Cursor, GitHub Copilot, OpenCode, Codex, Gemini, Qwen, Hermes, Windsurf, Cline, Grok, Aider and Pi. If your workflow is a chat window where you paste a diff and describe the problem in prose, Crit adds a binary and a browser tab without removing that habit. The value only appears when the agent can read the review file Crit writes and act on it.

Four review modes behind one command name

The mechanism is argument dispatch. Run crit with no arguments and it auto-detects changed files in the repository, then shows syntax-highlighted diffs. Pass a markdown path and it renders that file with formatting and a review UI. Pass an http URL and it proxies the running dev server and layers a review interface on top. Pass an HTML file and it renders the static artifact. The README gives the four forms side by side.

Comments are the output of all four modes. Click a line number to comment, drag to select a range, and comments render inline after the lines they reference, in the style of a GitHub pull request review. After the agent edits the file, Crit shows a split or unified diff of what changed, toggled in the header. The review file itself lives under ~/.crit/reviews/ by default, and crit comment appends to it, creating it when it does not exist.

Session identity is the part worth understanding before you rely on it. If multiple review sessions match the same directory and branch, an unqualified command fails rather than guessing, and you select one with --session <id> on crit comment, crit comments, crit share, crit push or crit pull. That failure is deliberate. It is also the first thing that will confuse a scripted workflow that assumes a single active session per repository.

Installing Crit and running a first plan review

The README offers Homebrew, Go, Nix and a Windows download. Homebrew is the shortest path on macOS and Linux.

brew install crit

After that, crit should be on your PATH. The Go route is go install github.com/tomasz-tomczyk/crit/cmd/crit@latest, and the README notes Nix via nix profile install github:tomasz-tomczyk/crit. Windows users download crit-windows-amd64.exe from the latest release and move it somewhere on PATH; the README says ARM64 users should swap amd64 for arm64 and WSL users should take the Linux binary instead.

The agent integration for Claude Code is two commands, run once. The first registers the plugin marketplace, the second installs the plugin.

claude plugin marketplace add tomasz-tomczyk/crit
claude plugin install crit@crit

For a first real review, point Crit at a markdown plan the agent produced. This renders the file with formatting and opens the review interface.

crit plan.md

Leave inline comments in the browser, then tell the agent to read the review file. The README says most integrations ship a /crit slash command that automates the whole loop: the agent launches Crit, waits for your review, acts on the feedback, and the cycle repeats until you approve. For a branch or pull request, crit story can generate an optional chaptered overview of the diff before you start, documented in docs/story-mode.md. Two utility commands are worth knowing early: crit status shows the review file path and daemon status, and crit cleanup deletes stale review files.

Live mode and the cookie problem it does not hide

crit live <url>, or crit <url>, proxies a running dev server through the review UI. The README is unusually candid about the failure mode: Crit's iframe loads the app on a different origin and port than your browser tab, so host-scoped session cookies are not shared automatically. If the direct URL works but Crit shows a login page or a hydration mismatch, the cause is usually cookies, not the app.

Three forwarding options are documented. A one-off cookie flag, a cookie file in Netscape jar format or raw Cookie header lines, and a Chrome DevTools Protocol URL that lets Crit read cookies for the target origin from a Chrome session started with remote debugging.

crit live http://localhost:4000/dashboard --cookie "_crit_key=..."
crit live http://localhost:4000/dashboard --cookie-file .crit/live-cookies.txt
crit live http://localhost:4000/dashboard --cdp-url http://127.0.0.1:9222

The same settings can be persisted in a global or project .crit.config.json, with the project file overriding the global one. Relative paths resolve from the repository root, and the README recommends a gitignored file under .crit/ over committing live_cookie inline.

{
  "live_cookie_file": ".crit/live-cookies.txt",
  "live_cdp_url": "http://127.0.0.1:9222"
}

This is the weakest seam in the product. Cookie export is manual, the CDP route requires launching Chrome with remote debugging, and neither is something you want in a shared CI environment. Live mode is a local development convenience, and the README treats it that way.

Programmatic comments, session IDs and where review state lives

Agents can write comments without opening the browser, which is what makes the loop scriptable. crit comment takes a file and line or line range plus a body, and appends to the review file. A --json flag accepts a JSON array on stdin for bulk comments, and --session targets a specific review when more than one matches.

crit comment src/auth.go:42 'Missing null check'
crit comment src/handler.go:15-28 'Error handling issue'
crit comment --session 839f3b4cd5d6 src/auth.go:42 'Target this review'
echo '[{"body":"Overall feedback"}]' | crit comment --session 839f3b4cd5d6 --json

The --output flag controls where the review file lands. The default is ~/.crit, which maps to ~/.crit/reviews/<key>/, while --output .crit writes to .crit/reviews/<key>/ inside the repository. That distinction matters for teams: the in-repo location is visible to everyone who clones, and the README does not document a cleanup policy for it beyond crit cleanup. The --clear flag removes the review file outright.

Sharing is the escape hatch from local-only review. The Share button uploads a review and returns a public URL that anyone can open without installing anything, with each reviewer's comments color-coded by author, and unpublish at any time. The CLI equivalent is crit share, which can also print a QR code in the terminal or target an organization with --org.

What Crit is not, and where a diff viewer wins

Crit is not a code review platform. There is no merge gate, no approval state that blocks a branch, and no per-reviewer permission model described in the README. The share URL is a link to comments, not a review workflow. If your process requires an audit trail tied to a pull request, GitHub's own review UI already does that, and Crit's comments would have to be copied there by hand.

Compared with a plain diff viewer or a terminal pager, the difference is where the feedback goes. A pager shows you the same lines Crit shows you. Crit's contribution is that the comment you leave is written into a file the agent can read, so the correction path is mechanical rather than a paragraph you retype into a chat. That is also its constraint: the loop only closes if your agent can read that file and run the command, which is exactly the condition the README states up front.

Story mode is the one feature that has no equivalent in a diff viewer, and the README describes it as optional and aimed at larger branch, pull request or range reviews. It generates a chaptered overview of the diff before you review it, with a custom prompt setup documented separately. For a three-line change it is overhead. For a branch that touches thirty files, reading a chaptered summary first is a reasonable use of the same binary.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-28, the same day as the v0.19.1 release. The two prior releases, v0.19.0 and v0.18.4, landed on 2026-08-18 and 2026-08-05, so the release cadence over that window is roughly weekly. That is the whole of what the release history supports; it says nothing about the size of the maintainer group or how long the cadence holds.

Crit is MIT licensed. That permits commercial use and modification, and it means you can vendor the binary or fork it. It does not tell you anything about the licence of the vendored frontend assets, and the repository layout suggests that question is taken seriously: there is an ASSETS-PROVENANCE.txt file, an asset-budget.json, and Makefile targets named verify-assets and verify-assets:installed that regenerate the vendored bundles and fail the build if the working tree changes. If you redistribute a modified Crit, those files are where you would start. Nothing here is legal advice.

Upgrade cost is low by construction. It is a single binary, so brew upgrade or a fresh go install replaces it, and the review files under ~/.crit/reviews/ are plain data the new binary reads. The one thing to watch across versions is the integration plugin, which is installed separately through the agent's own marketplace command. There is no documented migration step for review files between versions, and the README does not document rollback.

Editorial conclusion

Adopt Crit if you already run an agent that can read a file and run a command, and you want the review step to happen in a purpose-built interface instead of a chat window. Skip it if your agent workflow is one-shot, or if you need a hosted, multi-user review product rather than a local binary plus an optional share URL. Before installing, check the integrations/ directory for your agent, confirm which of the four review modes matches your output, and decide whether review files should live in ~/.crit or in a gitignored .crit/ directory inside the repo.

Frequently asked questions

Official sources

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