Crit: a local review UI that turns agent output into something you can actually point at

What Crit actually solves

Agents like Claude Code, Cursor, or Copilot produce text: plans, diffs, HTML artifacts. For the agent, that text is just tokens. For a human reviewer, a markdown plan and a running web app demand completely different attention. Crit gives each output type a dedicated interface: a rendered markdown view for plans, a syntax-highlighted diff for code changes, and a proxied browser view for a live app. The point is not to display text better. The point is to let you attach a comment to the exact line or range that is wrong, and then hand that comment back to the agent. Without such a tool, you either paste a screenshot and hope the agent guesses the location, or you copy a code snippet into the chat and describe the problem in words. Crit replaces that fuzzy loop with a structured one. It is for engineers who review agent work regularly, not for occasional users who can tolerate copy-paste.

The mechanism: a local review file and a daemon

Crit does not run as a cloud service. It is a single binary that runs locally and writes your comments to a review file stored under ~/.crit/reviews/. The CLI commands crit comment, crit comments, crit share and crit push all operate on that file. When you run crit with no arguments, it auto-detects git changes and shows a diff. When you run crit plan.md, it renders that file. When you pass a URL, it proxies the running dev server through its own UI. The key architectural choice is that the review state lives in a plain file on disk. That makes it agent-friendly: an agent can read the file, see your comments, and act on them. It also makes it scriptable: you can pipe JSON into crit comment --json to add comments programmatically. The daemon status is visible via crit status. This file-based design is what allows Crit to integrate with any agent that can read a file and run a command. There is no proprietary protocol, no API key, no server to deploy.

Getting it running: install, config, and the /crit command

Installation is straightforward. On macOS with Homebrew: brew install crit. On Go: go install github.com/tomasz-tomczyk/crit/cmd/crit@latest. On Nix: nix profile install github:tomasz-tomczyk/crit. Windows users download a binary and put it on PATH. After installation, the recommended integration for Claude Code is two commands: claude plugin marketplace add tomasz-tomczyk/crit and claude plugin install crit@crit. Other agents get instructions in the integrations/ directory. The typical loop is: your agent finishes a task, you run /crit (or crit manually), review the rendered output, add comments, and paste the resulting prompt back to the agent. The agent then edits and you repeat until approval. For live mode, you may need to forward cookies because the iframe runs on a different origin. The config file .crit.config.json supports live_cookie_file and live_cdp_url. You can also pass --cookie, --cookie-file, or --cdp-url directly on the command line. The README is explicit about the cookie pitfall: host-scoped session cookies are not shared automatically, so a login page or hydration mismatch is expected unless you forward them.

Round-to-round diffs and inline comments

The two features that make Crit useful for iterative work are the round-to-round diff and range-based inline comments. After your agent edits a file, Crit shows a split or unified diff of what changed since your last review. That lets you verify only the delta, not the whole file. Inline comments work like a GitHub PR review: click a line number to comment on that line, drag to select a range. Comments render inline after their referenced lines. The CLI exposes the same capability through crit comment, which accepts a file and line or range, for example crit comment src/auth.go:42 'Missing null check'. This is not just a convenience. It is the mechanism that lets an agent programmatically add review comments without opening the browser. The README shows piping JSON into crit comment --json, which means a CI script or another agent could inject feedback. The combination of a file-based review state and a CLI that mirrors the UI actions is what separates Crit from a simple markdown viewer.

Live mode and the cookie forwarding tax

Live mode is the most ambitious part of Crit and also the most fragile. When you run crit http://localhost:3000, Crit proxies your running app and injects its review UI into an iframe. That iframe loads the app on a different origin or port than your browser tab, so host-scoped session cookies are not shared. The README is refreshingly honest about this: it says if the direct URL works but Crit shows a login page or hydration mismatch, you need to forward upstream cookies. You can do that one-off with --cookie, repeatedly with --cookie-file, or automatically with --cdp-url pointing to a Chrome remote debugging port. The config file lets you set live_cookie_file and live_cdp_url globally or per project. This is a real operational cost. For a simple static HTML file, crit landing.html works with no cookies. For a live app with authentication, you must either export a cookie jar or run Chrome with remote debugging enabled. That is a non-trivial setup for a tool that claims to be a single binary. The trade-off is clear: the power of reviewing a live app directly comes with the burden of managing session state.

Sharing reviews for async review

Crit also supports asynchronous review, which is useful when you want a second opinion before handing off to the agent. The Share button uploads your review and returns a public URL that anyone can open in a browser, no install needed. Each reviewer's comments are color-coded by author, and you can unpublish anytime. The CLI mirrors this with crit share plan.md, which prints the URL, and crit share plan.md --qr to also print a QR code. There is also an --org flag, though the README truncates before explaining what it does. Sharing has a real privacy implication: the URL is public unless you publish to an org, and the README does not describe any access control beyond unpublishing. If your review contains sensitive code snippets, think twice before clicking Share. The async flow is a nice complement to the synchronous loop, but it is not a replacement for a proper code review tool with permissions.

Limitations and where Crit is the wrong tool

Crit has several genuine limitations. First, it depends on the agent being able to read a file and run a command. If your agent is a hosted chat with no file access, Crit cannot integrate. Second, the review loop is only as good as the agent's willingness to act on comments. Crit does not enforce anything; it just writes comments to a file. If your agent ignores the feedback, you have a nice UI and no outcome. Third, live mode requires cookie management, which is a maintenance burden for apps with complex authentication. Fourth, the README does not describe any conflict resolution for multiple reviewers editing the same review file, so concurrent async reviews could clobber each other. Fifth, Crit is not a code review tool in the sense of GitHub PR reviews: it has no approval workflow, no merge blocking, no integration with CI. It is a feedback channel, not a governance layer. For teams that need auditable, enforced review gates, Crit is the wrong tool. For a solo developer or a small team iterating with an agent, it can be exactly right.

Alternatives and how they differ

The closest alternative is a standard code review tool like GitHub's pull request review or Gerrit. Those tools integrate with your git host, enforce approvals, and provide a persistent audit trail. Crit does none of that: it is a local, file-based, agent-agnostic review UI. The difference in approach is fundamental. GitHub PR review is server-side and tied to a repository; Crit is client-side and tied to your local filesystem. Another alternative is simply using your editor's diff view and typing comments in a chat. That works but loses the structured, line-referenced format that Crit provides. There is also the approach of using a dedicated agent like Aider with its own review loop, but that ties you to one agent. Crit's differentiator is that it is agent-agnostic: the README lists Claude Code, Cursor, GitHub Copilot, OpenCode, Codex, Gemini, Qwen, Hermes, Windsurf, Cline, Grok, Aider, and Pi. That breadth is both a strength and a weakness. A strength because you can switch agents without changing your review workflow. A weakness because the integration depth varies: Claude Code gets a plugin, others get instructions in a directory.

Maintenance and license

Crit is written in Go, which produces a single static binary. That is a maintenance advantage: no runtime dependencies, no Node modules, no Python environment. The project is under the MIT license, which means you can use it commercially, modify it, and redistribute it with attribution. The repository shows recent releases (v0.19.1 in August 2026) and an active default branch, but the README does not describe a migration path for review files across versions. If the review file format changes, you might lose access to old comments. The project also provides a cleanup command (crit cleanup) to delete stale review files, which suggests that review files can accumulate. There is no mention of an upgrade mechanism beyond downloading a new binary, so you are responsible for keeping it current. The maintenance cost is low because the tool is self-contained, but the lack of a documented upgrade path for stored reviews is a small risk.

Editorial conclusion

Adopt Crit if you spend more than a few minutes per day reading agent-generated plans or diffs and you want to comment on exact lines instead of pasting text back into a chat. Skip it if your agent cannot run arbitrary commands or you refuse to grant that level of access. Before adopting, verify that your specific agent integration exists in the integrations/ directory, test the cookie forwarding for live mode with your app, and confirm that the review file format (JSON under ~/.crit/reviews/) matches your workflow for exporting comments. Crit is not a governance layer: it does not enforce that the agent actually fixes anything, it only gives you a channel to say what is wrong.

Official sources

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