The checkout's installer stopped before code review could start
Our attempt to install Open Code Review failed after 8 seconds, before we could use its review workflow. That matters because the attraction is practical: choose a Git change, give the reviewer a model, and get comments tied to particular lines. Alibaba's CLI separates file selection and rule matching from the model's reasoning. It looks worth evaluating for teams tired of an assistant choosing its own review scope.
The checkout's installer selected version 0.0.0 and requested a GitHub release binary that returned HTTP 404. That is a specific obstacle for someone installing the cloned source with npm. It does not establish that the published npm package fails too. The English README recommends the globally published package, and the project also distributes native binaries. Keep those routes separate when deciding whether to try it.
What happened when we ran it
Our run of commit 182898c on October 8, 2026 failed its npm install in 8 seconds with exit code 1. The fresh Debian sandbox used image lab-node:22, 3 CPUs and 8 GB of RAM. It ran without elevated privileges or secrets. The checkout contained 956 files, roughly 159,965 lines of source, and occupied 14.1 MB before installation.
The failing step was node scripts/install.js. It detected linux/amd64, read 0.0.0 from package.json, and tried to download opencodereview-linux-amd64 under the v0.0.0 release path. GitHub answered HTTP 404, and npm stopped. The log shows a failed binary download. It supplies no evidence of missing Debian packages, a compiler failure, or an authentication problem, so none explains this result.
The sandbox scan found 12 CI workflow files, no Dockerfile, and no tests directory. Those observations do not prove that the repository lacks tests or container support elsewhere. The supplied measurement contains no build or test outcome, and the failed install leaves review quality unmeasured. We can describe the failure precisely without treating workflow files as evidence that a review would succeed.
Released binaries offer a separate route from version 0.0.0
The latest release, v1.12.13, includes a Linux amd64 binary and a checksum file. Those assets are different from the v0.0.0 URL that failed in our sandbox. GitHub identifies Go as the primary language, despite our npm-based setup path. The installation guide explains that the static binary can run without Node.js. We have no measured result for that route.
Git 2.41 or newer is a documented prerequisite. Another operational detail deserves attention: the npm wrapper checks for updates in the background and upgrades automatically by default. Set OCR_NO_UPDATE=1 if your team controls upgrades explicitly, or consider the static binary, which opts out. A version pinned in an npm command needs that update policy beside it if repeatability matters.
File rules make the review scope inspectable
The 956-file checkout helps explain why explicit selection matters: a reviewer needs a way to decide what deserves attention. OCR can review workspace changes, a branch range, or a single commit. Its scan command examines whole files without requiring a meaningful diff. Related files can be bundled for review, and the agent can read surrounding code or search for context before producing comments.
Rule files let you target checks by path, such as request validation in API handlers. Read the rule matching details carefully: the first matching rule wins, and a custom rule replaces the system rule unless you request a merge. An include pattern bypasses certain default exclusions rather than defining an exclusive file list. Inspect the resolved rules before assuming your security checklist applies everywhere.
A local model still needs working tool calls
Our 3-CPU, 8 GB sandbox result says nothing about the resources needed to serve a local review model. The normal workflow requires a configured endpoint, model selection, and provider credentials where applicable. OCR sends changed code to that endpoint and gives the agent tools for retrieving context. Choose a provider your organization permits to receive that code, then check connectivity with ocr llm test.
The configuration reference documents an Ollama endpoint, but requires a model with native tool calling and a nonempty placeholder API key. Delegation mode is another useful choice: OCR selects files and resolves rules while your existing coding agent performs the review. Claude Code plugins support that workflow. Delegation avoids a separate OCR model endpoint, while still requiring the CLI and a host agent.
Optional MCP tools send context beyond the checkout
OCR acts as an MCP client, so its agent can consult an external documentation or ticket service during review. The MCP connection guide says remote tool calls proceed without asking each time, and user configuration applies across repositories. Set an explicit tool allowlist and decide which repositories may use the connection. Teams that prohibit external context requests should leave those services disconnected.
Current activity does not make the JSON contract settled
The repository was pushed on October 10, 2026, and GitHub listed 45,797 stars plus 291 open issues and PRs. Release v1.12.13 shipped on October 8 with scan-path and timeout-diagnostic fixes. Recent issue reports and proposed fixes show ongoing work. That is evidence of maintenance, although neither popularity nor a recent release resolves our checkout's 0.0.0 download failure.
Issue 1696 reports that v1.12.13 returns null for a repository with no session directory and [] when an empty directory exists. The issue remained open, with a proposed fix in PR 1699. Wrapper authors should normalize that result. For PR-centered AI automation, compare PR-Agent. For existing linter findings, choose reviewdog; for explicit static-analysis rules, consider Semgrep. I'd evaluate OCR as advisory feedback after verifying the chosen distribution, and keep a human responsible for accepting its comments.