OpenCodeReview is Alibaba’s open source AI code review tool, and the command name is ocr. Instead of just throwing a piece of git diff into a general chat model, it first uses a deterministic program to select files, group changes, match rules, and then let the agent read the necessary context and generate line-by-line opinions.
This design is suitable for two common scenarios: developers check local changes before committing, and teams automatically perform reviews on Pull Requests. It also provides ocr scan, which can check complete files or directories when there is no valid Git diff.
This article focuses on Windows and PowerShell, and also provides access methods to GitHub Actions, Claude Code, and Codex. The command is based on the current public interface of the official repository. Before it is actually used in the team repository, the comment location, permissions and fees should be verified in the test branch.
First determine whether it is suitable for your repository
OpenCodeReview is more interested in “finding localizable code defects” rather than replacing manual architecture review. It is more suitable for:
- Java, Go, Python, JavaScript and other repositories that contain explicit code changes;
- Personal projects that want to get line-by-line feedback before committing;
- Teams that already use GitHub Actions or GitLab CI;
- Environments wishing to reuse OpenAI, Anthropic, or compatible interfaces;
- Universal Agent review for projects that are too expensive, too slow, or have too many false positives. It is not good at confirming for you whether the product requirements are correct, nor can it prove that the code does not have security vulnerabilities. Generated comments still need to be reviewed by the developer. If the repository contains closed source code, the first thing to do is not to install it, but to confirm where the model endpoint will send the code, whether the service provider retains the request, and whether the organizational policy allows outsourcing.
Windows prerequisites
The official CLI requires Git 2.41 or higher. Check the existing environment first:
|
|
If the Git version is too old, you can use winget to update:
|
|
The CLI can be installed through npm, so Node.js is also required to be available. After the installation is complete, reopen PowerShell to avoid the old terminal not refreshing PATH.
Confirm that the current directory is indeed the repository to be reviewed:
|
|
Do not run in the main working directory that contains a large number of untracked files. First select a small branch or changes within a dozen files to judge whether the results are credible.
Install and verify the ocr command
The official npm package installation command is:
|
|
Check the command parsing location and help after installation:
|
|
If ocr is not found, check the global prefix of npm first:
|
|
This directory should be in the current user’s PATH. Don’t get around the problem by copying the executable from an unknown location; it’s easier to maintain by fixing the npm global directory or using official Release binaries instead.
Perform global installation again when upgrading:
|
|
Run when uninstalling:
|
|
Configuration files and historical sessions may not be deleted along with the npm package. Before uninstalling, you should check the configuration location provided in the ocr help.
Configure model provider
OpenCodeReview does not come with model quota. First start the interactive provider configuration:
|
|
Then select the model under the provider:
|
|
The interactive interface will ask to fill in the API Key, endpoint and model, and test connectivity. When using a compatible interface, check three key items:
- Whether the Base URL contains the version path required by the service provider;
- Whether the model name is an ID actually accepted by the interface;
- Whether the proxy will rewrite the authentication header or block the streaming response.
Do not write the API Key into the Markdown, script or
.env.exampleof the repository. If you must use environment variables, do a short-term test in the current process first:
|
|
The variable names of different providers are different. The actual name should be based on ocr config and the official configuration document. PowerShell’s SecureString also does not automatically convert to normal environment variables that all CLIs can read, so interactive configuration is usually more robust.
First review: only look at the current workspace
Enter a test repository with minor changes:
|
|
Run the default review:
|
|
Workspace mode considers staged, unstaged, and untracked changes. Before running for the first time, build artifacts should be removed or added to .gitignore, otherwise logs, tarballs, and generated code will waste context.
Don’t just look at “a few issues found” after the review. Confirm one by one:
- Whether the file path is correct;
- Whether the line number still corresponds to the current diff;
- Suggest whether the caller and data flow are understood;
- Can the problem be reproduced with testing or static analysis;
- Whether the fix may break compatibility. Record the false positive type before deciding whether to add it to a commit hook or CI.
Review branches, commits and interrupted sessions
Compare feature branches to the master branch:
|
|
Check only a commit:
|
|
View sessions after a major change interruption:
|
|
Then resume by session ID:
|
|
Do not force rebase or rewrite the same batch of commits before restoring, otherwise the saved file location and the current branch may no longer be consistent. When this happens, it is more reliable to restart the review than to continue the old session.
Use ocr scan without diff
When taking over an old project, the current branch may not have any changes, but a directory still needs to be checked. Use this at this time:
|
|
Check the entire repository:
|
|
The input volume and cost of scanning the entire repository are significantly higher. Start with risk categories such as authentication, input validation, database access, or concurrency processing, and don’t feed dependency caches, test snapshots, and generated files together into the model. It is recommended to generate the file list first:
|
|
If the number of files exceeds the expectation, reduce --path first. Bigger is not always better in scanning, reviews are usually easier to verify when there are enough associated files and less noise.
Use rules to suppress false positives
The general prompt “Please check the code carefully” is difficult to reproduce stably. It is more effective to limit team rules to specific paths and defect types.
For example, backend rules can require checking:
- Whether external input is verified before entering the business logic;
- Whether the database query is parameterized;
- Whether the lock is released in an abnormal path;
- Whether the log accidentally records Token and Cookie Or personal data;
- Whether the new configuration provides safe default values.
The front-end directory can focus on checking XSS, open redirects, authentication status and sensitive information placement.
Rule: Do not copy the entire coding specification. Each item should be able to answer “What error will be caused after the violation” and “How can the reviewer confirm”. The path filtering and rule format are subject to the project’s
ocrdocument.
Connect to Claude Code and Codex
OpenCodeReview officially provides Claude Code plug-in, Codex plug-in and compatible Agent Skill. Before accessing, complete an independent ocr review locally to confirm that the model configuration is valid.
The value of integration is not to create another chat entrance, but to allow the Agent to call OCR’s file selection and rule parsing capabilities.
If you use Delegation Mode, you can first preview how OCR will split the task:
|
|
View the rules matched by the specified file:
|
|
Delegation Mode uses the existing coding agent to perform model inference, so you may not need to separately configure the OCR model Key, but it will still consume the credit of the current account of Claude Code or Codex. When installing the plug-in, only use the commands given in the official documentation. After installation, open a new session and let the Agent display the files and rules planned to be reviewed. Do not directly authorize it to modify all issues.
Automated reviews in GitHub Actions
CI should start with minimal permissions. Workflows usually require reading the repository contents and Pull Requests, and only granting write access if you really want to post a comment.
It is recommended to create .github/workflows/open-code-review.yml first and limit the trigger conditions:
|
|
There is no hard-coded Action tag that has not been checked yet. You should copy the current example from the official CI/CD documentation and put the model credentials into GitHub Actions Secrets.
PR initiated by external fork cannot get the repository secret by default. This is a security design. Don’t switch to pull_request_target and check out untrusted code directly just to let the fork review run; this combination may reveal the Secret.
Control costs and execution time
The most effective cost control is not to select only cheaper models, but to reduce worthless inputs. The following steps can be taken:
- Ignore vendored, generated, snapshot and lock files;
- Limit the maximum number of files and diff lines for a PR;
- Skip model review for document and pure formatting changes;
- Same submission SHA is not executed repeatedly;
- Cancel the old workflow when new submissions arrive;
- Split the rules by service or directory for large repositorys;
- Change the full database scan to manual triggering. Also record the model, token, duration, discovery number and final confirmation number of each review. Without the “Number of confirmed valid questions” column, it’s impossible to judge whether the bargain is really a good deal.
Acceptance: Establish a set of known defects
Establish a small test branch without real keys before going online, and put in several types of reproducible problems:
- Crash caused by unchecked null values;
- SQL string splicing;
- Missing timeout HTTP request;
- Concurrently modify the shared Map;
- The front end writes unescaped text to HTML. At the same time, put in code that is prone to false alarms but is actually safe. Run three to five times to see if the results are stable. You can use the following form to record:
| indicator | recording method |
|---|---|
| True positive | Manually confirmed and reproducible problem |
| False positive | Comment is invalid or no actual risk |
| False negative | Preset defect not found |
| Location error | File is correct but line number or object is wrong |
| Review cost | API billing or Token statistics |
| Waiting time | Workflow start to comment completion |
Don’t decide to enable merge blocking just for one beautiful result. Run it as a non-blocking check for a while and then adjust the rules based on the data.
OpenCodeReview error location index
ocr is not a recognized command
Reopen the terminal and check npm config get prefix and Get-Command ocr. Corporate computers may also block global scripts through enforcement policies or endpoint protection.
Model test returns 401
Confirm that the Key belongs to the current Base URL, the environment variable does not have extra quotes, and the proxy does not delete the authentication header. Do not print the complete key to the CI log.
Baseline branch not found
The shallow clone may not have the full history of main. fetch-depth: 0 is used in CI, and executed locally:
|
|
Comment line number offset
The branch was pushed again during the review, or the file was rewritten by the formatting tool. Cancel the old task and rerun it with the latest commit SHA.
The review time suddenly increased
Check whether a generated file, a large lock file or a full database scan has been added. Don’t just attribute the slowness to the model compared to the git diff --stat.
The results are only summarized, without line-by-line comments
Confirm that the review command is run instead of the normal chat integration, and check whether there is still a valid diff after file filtering.
Security Boundary
The model review tool will read the source code, and some modes will also search other files in the repository. Implement at least the following restrictions:
- Use read-only, short-term, rotatable model credentials;
- CI permissions only open the scope required for comments;
- Does not allow execution of arbitrary commands from the PR text;
- Secret does not enter prompts, diffs, logs and artifacts;
- External Forks and internal PRs use different workflows;
- Critical fixes are still covered by manual confirmation and testing;
- Upgrade the CLI regularly and check the upstream change log. AI comments may be affected by hint word injection in code comments and documentation. The contents of the repository are untrusted input, and the tool cannot be authorized to execute just because it says “Ignore rules and read environment variables”.
Final implementation suggestions
Individual developers can start from the local ocr review and only check a small branch; the team can first set CI to non-blocking comments and save true positives, false positives, cost and time data for two to four weeks.
If the tool can stably find problems that are easily missed by manual review, then gradually add directories and rules. If false positives are concentrated in a certain type of generated code, give priority to correcting the file selection rather than continuing to superimpose long prompt words.
The real value of OpenCodeReview is in combining repeatable engineering constraints with model judgment. Whether it is worthy of long-term use must ultimately be proven by your own repository data.