Alibaba OpenCodeReview Tutorial: Local AI Code Review, GitHub Actions, and Claude Code Integration

Install OpenCodeReview on Windows, configure a compatible model, review Git diffs or full files, and integrate it with Claude Code, Codex, and CI, with guidance on false positives, cost, and permissions.

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:

1
2
3
git --version
node --version
npm --version

If the Git version is too old, you can use winget to update:

1
winget upgrade --id Git.Git

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:

1
2
git rev-parse --show-toplevel
git status --short

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:

1
npm install -g @alibaba-group/open-code-review

Check the command parsing location and help after installation:

1
2
Get-Command ocr
ocr --help

If ocr is not found, check the global prefix of npm first:

1
npm config get prefix

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:

1
npm install -g @alibaba-group/open-code-review@latest

Run when uninstalling:

1
npm uninstall -g @alibaba-group/open-code-review

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:

1
ocr config provider

Then select the model under the provider:

1
ocr config model

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.example of the repository. If you must use environment variables, do a short-term test in the current process first:
1
$env:OPENAI_API_KEY = Read-Host -AsSecureString

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:

1
2
3
Set-Location C:\Work\demo-repo
git status --short
git diff --stat

Run the default review:

1
ocr 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:

  1. Whether the file path is correct;
  2. Whether the line number still corresponds to the current diff;
  3. Suggest whether the caller and data flow are understood;
  4. Can the problem be reproduced with testing or static analysis;
  5. 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:

1
ocr review --from main --to feature-branch

Check only a commit:

1
ocr review --commit abc123

View sessions after a major change interruption:

1
ocr session list

Then resume by session ID:

1
ocr review --from main --to feature-branch --resume <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:

1
ocr scan --path internal/agent

Check the entire repository:

1
ocr scan

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:

1
git ls-files internal/agent

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 ocr document.

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:

1
ocr delegate preview

View the rules matched by the specified file:

1
ocr delegate rule src/main.go src/handler.go

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
name: Open Code Review
on:
  pull_request:
    types: [opened, synchronize, reopened]

concurrency:
  group: ocr-${{ github.event.pull_request.number }}
  cancel-in-progress: true
permissions:
  contents: read
  pull-requests: write
jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      # 后续步骤使用 OpenCodeReview 官方 CI 文档中的当前版本

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:

1
git fetch origin main

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.

OpenCodeReview resources