roborev: Local Continuous Code Review for Coding Agents

Why roborev Reviews Every Commit

roborev addresses a specific gap in agent-assisted development: coding agents can produce several commits before a person pauses to inspect them. Its solution is to attach review to the commit boundary rather than wait for a pull request or remote review service. After initialization, each commit starts a background review. The intended users are developers whose coding agents already operate locally and repositories where code review needs to keep pace with frequent changes.

The project stores review activity locally and uses configured coding agents to perform review work. It supports a wide agent set, including Codex, Claude Code, Gemini, Copilot, OpenCode, Cursor, Kiro, Kilo, Droid, and Pi. The browser interface also lists supported profiles, but hook installation is auto-detected rather than guaranteed for every product named in the feature list. Compatibility should therefore be checked against the documentation for the exact agent in use.

roborev does not introduce a separate hosted review workflow. That is useful for local-first development, but it also means its behavior depends on the agents, credentials, model access, and network configuration already present on the machine. The README states that no hosted service or additional infrastructure is required. It does not promise that reviews can run without model access, and it does not document a model-independent static analysis engine for the complete review flow.

Post-Commit Hooks and Agent Feedback

The automation has two layers. The first is a Git post-commit hook installed by `roborev init`. When a commit is created, roborev schedules review work in the background. This makes the trigger independent of which coding agent authored the change. The second layer is optional: `roborev agent-hook install` detects supported coding-agent harnesses and connects queued findings to active sessions.

Agent hook callbacks send events to the roborev daemon. The daemon evaluates reminder thresholds and stores session counters and delivered review IDs in `${ROBOREV_DATA_DIR:-~/.roborev}/agent-hook/state.json`. This persistence prevents the hook infrastructure from treating every callback as a new session. The documented threshold concepts include configured turn, commit, and failed-review triggers.

The callback path is designed to fail open. If the daemon is unavailable, the hook does not block the coding agent. That is a deliberate availability trade-off. Review reminders can be delayed or missed when the daemon is down, but the primary agent workflow continues. Supported behavior differs by harness. Hermes delivers queued post-tool reminders at `Stop`, while Cursor records events but emits no control response. Those distinctions matter for teams that assume every adapter can interrupt an active session.

roborev Quick Start With Git and the TUI

The README links to the installation documentation but does not provide a binary installation command. Start at the documented installation page, then use the following quick-start sequence in an existing repository. The `roborev quickstart` command is also mentioned as an option for new users.

The first real use starts by moving into the repository and installing the post-commit hook:

cd your-repo
roborev init

After initialization, create an ordinary commit. According to the README, roborev begins reviewing it in the background:

git commit -m "..."

Open the terminal interface to inspect the review queue. Its documented interface supports vim-style navigation, with a split-screen layout on large terminals:

roborev tui

For a browser-based view, use:

roborev ui

The `roborev ui` command opens the native interface embedded in the local daemon. The documentation says this view supports filtering, inspection, comments, closure, cancellation, reruns, and Analytics. A first-use verification should therefore include creating a commit, waiting for its review record, and confirming that the same commit can be located in the chosen interface.

If roborev is managed by a version manager, initialization tries to use a stable shim or symlink. The README also documents selecting an exact executable with `--binary`:

roborev init --binary ~/.local/share/mise/shims/roborev

The same binary option is available for `agent-hook install`. This matters when an agent session cannot resolve the version-managed executable through its normal environment.

Review Storage, Findings, and Verification

roborev is described as a continuous background code review database. Completed reviews can be searched across repositories by keyword or meaning. Lexical search remains local and does not require an embedding provider, while semantic and hybrid modes are optional. This separation gives local users a basic search path without requiring every deployment to configure another service.

Findings can enter an agent workflow in several ways. Users can copy review text into an interactive agent, invoke `/roborev-fix` in Claude Code or `$roborev-fix` in Codex, or run `roborev fix` from the command line. The fix command presents findings to an agent, which applies changes and commits them. Because that new commit triggers the post-commit hook, review can continue without manually returning to the queue.

roborev also provides a verification command, `roborev compact`, which checks findings against current code, filters false positives, and combines related issues. That matters when an automated agent fixes findings in sequence. Without revalidation, a later code change can make an earlier finding obsolete or can resolve several reported causes at once.

False positives remain a real concern for any agent-driven reviewer. The documentation provides compacting and rebuttal workflows, but it does not claim perfect detection. The relevant distinction is that roborev retains review history and supports verification and response rather than treating each generated finding as an unquestionable defect.

roborev Fix and Refine Failure Boundaries

The `fix` workflow is direct but changes repository state. The documented command asks an agent to apply fixes and commit them:

roborev fix

Developers who want planning included can use:

roborev refine --plan
roborev refine --plan-only

`roborev refine` runs in an isolated worktree and repeats a cycle of fixing findings, waiting for re-review, and fixing again. It stops when every review passes or when `--max-iterations` is reached. This isolation is useful because an automated sequence may edit several files over multiple commits, but the README does not explain cleanup behavior, merge instructions, or recovery when the iteration limit is reached.

The loop can also amplify bad assumptions. A reviewer can request a change, an agent can implement that request incorrectly, and the resulting commit can produce another finding. The stored-review and compact commands help with this cycle, but they do not remove the need to inspect diffs and commits before merging. The README does not document rollback, reviewer model selection, per-review cost controls, retry limits for failed agents, or what happens when an agent cannot apply a fix.

The explicit warning is that automated iteration is an advanced feature. For sensitive repositories or changes involving security boundaries, review output should be treated as advisory input. The documentation does not claim that roborev replaces human approval, dedicated security testing, or code review by a named team member.

Local Operation, Hook Events, and Upgrade Cost

roborev is implemented primarily in Go. The repository declares Go 1.27.0 in `go.mod`, and the README badge states Go 1.27.0 or later. Its repository also contains a Bun workspace for the web components, with `[email protected]` declared as the package manager in `package.json`. Contributors therefore face a mixed Go and Bun codebase rather than a single-toolchain repository.

Reviews and hooks are orchestrated on the developer’s machine. Agent hooks can run shell commands on review events, and the README lists built-in integrations for beads and kata. Shell hooks introduce a configuration surface that repository owners must inspect, especially if a review fails repeatedly. The README does not provide a comprehensive list of commands, event names, timeout behavior, or sandboxing rules, so those details must be verified in the project documentation before installation.

The repository is not archived, and its last push was on 2026-10-16. Releases listed for October 2026 include v0.71.0, v0.70.0, and v0.69.0. This indicates recent repository activity, but it does not establish compatibility with every agent or operating system. Upgrading may require checking hook paths, bundled skills, daemon state, and changes to CLI behavior.

The project uses the MIT License. That permits use, modification, distribution, and sublicensing under the license’s stated conditions, including preservation of its copyright and permission notice. This is a summary of the identifier rather than legal advice. Teams should also account for their coding agents’ own terms, model costs, data handling, and local retention policies.

roborev Compared with Remote Pull Request Review

The practical alternative is a conventional remote review process using pull requests and human reviewers. The approaches differ in timing and control. A remote pull request workflow centralizes discussion after changes are grouped and presented, while roborev starts review after every local commit through a post-commit hook. That makes roborev better aligned with short agent work cycles, but it can also create more review records than a team wants to consume.

roborev keeps orchestration local and feeds findings back into supported agent sessions. Remote review generally depends on a hosting platform, a pull request, reviewer availability, and a web or API workflow. The roborev documentation does not describe pull request creation, hosted branch synchronization, reviewer assignment, or mandatory approval policies. It should not be assumed to duplicate those controls.

The trade-off is cost of attention. roborev can review frequent commits and preserve a searchable history, but its local, agent-driven model depends on model availability and may produce findings that require rebuttal or compaction. A remote process may be slower for an individual commit but offers a clearer approval gate and a different human communication model. Some teams can use both, but the roborev documentation does not describe a supported integration workflow between them.

Editorial conclusion

Adopt roborev if your team commits frequent agent-generated changes and already has compatible coding agents configured. Do not choose it as a substitute for security assessment, policy enforcement, or offline review. Verify hook behavior, agent compatibility, data storage, review false positives, and the cost of configured agents before applying it across repositories.

Frequently asked questions

Official sources

1. kenn-io/roborev on GitHub
2. License: MIT
3. Project website
4. README
5. Releases