Open-Source AI Code Review in Claude Code: Alibaba Open Code Review vs OpenQodex

Open source AI code review sounds simple: point a tool at your change and get a list of bugs. In practice, the tools work in very different ways. Two free options for Claude Code are Alibaba’s Open Code Review and OpenQodex, so we installed both in a throwaway sandbox and ran them on the same small change.

This guide is part of our Claude Code tutorials. Find more add-ons in our skills directory.

Tested with Claude Code v2.1.318 on 2026-11-08, Open Code Review v1.13.6 (repo commit 0d40339) and OpenQodex 0.16.0 (repo commit 1ccd4c9).

What Is Open Source AI Code Review?

An AI code review tool reads the lines you changed and points out problems before a teammate has to. The usual targets are bugs, security holes, leaked secrets and missing error handling. The open source part means you can read the code, run it yourself and pay no license fee.

Claude Code already ships with its own review features. If you only want a quick local check, read our guide to local code review first. The two tools here add something extra: rules and file selection from Open Code Review, and real security scanners from OpenQodex.

The Demo Change We Reviewed

We built a tiny shop app in an empty git repo, committed it, then added a change with four problems on purpose. You can copy the idea for your own test.

• A find_user function that builds its SQL by joining strings (SQL injection).
• Two hardcoded keys named AWS_KEY and AWS_SECRET. They are the fake example values from AWS’s own documentation.
• An apply_discount function that divides the percent by 10 instead of 100.
• A database connection that is opened and never closed.

The old average_order function, which crashes on an empty list, was already in the base commit. We wanted to see whether the tools stayed focused on the change.

How We Kept Your Setup Safe

Both plugins run commands on your machine. The official plugin docs say that what a plugin runs, it runs as you, so we read every hook, command and skill file before trying anything. You can read how plugins load in the plugins docs and discover plugins page.

We did not use /plugin install. Instead we cloned both repos into a sandbox folder, installed the two command-line tools with npm install --prefix into that folder, and loaded each plugin with --plugin-dir and --setting-sources project. Small wrapper scripts pointed the tools at a throwaway home folder, so nothing was written to the real ~/.claude folder or the real home.

One change to say plainly: the OpenQodex plugin normally calls npx -y [email protected] from its hook and its MCP file. In our sandbox copy we pointed those two lines at our wrapper script. Everything else in the plugin is unchanged.

Test 1: Open Code Review in Claude Code

What the plugin adds

The Claude Code plugin in the repo is small. It holds two slash commands, /open-code-review:review and /open-code-review:delegate-review. Both call the ocr command-line tool, which you install with npm install -g @alibaba-group/open-code-review according to the README.

The review command runs ocr review --audience agent, which sends your diff to a language model that you configure with ocr config provider and an API key. We did not run that command, because the README says it needs a provider and key. The delegate-review command is different: the repo says delegation mode needs no model endpoint on the ocr side, because your coding agent does the thinking.

Running delegate mode

We started Claude Code in the demo repo and ran the command below.

claude --plugin-dir /path/to/open-code-review/plugins/open-code-review/claude-code --setting-sources project
/open-code-review:delegate-review

Claude Code asked for approval before each shell command. The first one was ocr delegate preview, which lists the files worth reviewing.

The preview reported one reviewable file out of two total, in workspace mode.

The second file was a __pycache__ folder that Python had left in the repo. Next, Claude ran ocr delegate rule app.py, which printed the review checklist for Python files. We saw rules such as dead code and mutable default arguments, plus a note to favor precision over recall.

What Claude found

After the rules, Claude read the diff and reviewed it with its own judgment. The result was a table of issues and the fixes it applied.

In our second run Claude listed all four problems we planted. In our first run it listed three and dropped the unclosed connection as low severity. That gap is worth knowing: the model does the judging, so two runs on the same change can differ a little.

It also reported what it left alone. It named the empty-list crash in average_order and said that code was already in the base commit. It said it only checked that the file still parses and did not run the app or any tests.

We checked the edit with !git --no-pager diff, which runs a shell command inside Claude Code. The discount function now divides by 100, and the hardcoded keys are gone.

Test 2: OpenQodex in Claude Code

Scanners first

OpenQodex takes a different approach. It runs real security scanners on the lines you changed, and only then involves a reviewer. On our first run it downloaded Semgrep 1.94.0, Gitleaks 8.21.2, OSV-Scanner 2.6.0, Ruff 0.8.4 and Bandit 1.9.4, then ran them.

Five scanners ran, 17 had nothing to check, and three candidates came out. Semgrep and Bandit both flagged the SQL line, and Bandit flagged the hardcoded secret as a possible password. None of the three candidates was the discount bug, because scanners look for known patterns and a wrong divisor is not one.

Then the run stopped with exit code 2 and the message “Full review unavailable”.

OpenQodex wants to start its own separate Claude Code process as the reviewer, and our throwaway home folder was not signed in. That is a result of how we isolated the test, not a flaw in the tool. The output suggested a second path: review --agent, where the Claude Code session you are already in does the review.

Running it through the skill

The plugin brings a skill named openqodex. Its instructions tell Claude to run the review command, show the receipt as printed, and ask whether to fix everything. The skill also says to run openqodex init if the tool is not installed, but that command rewrites your agent files, so we told Claude not to run it and gave it our wrapper path instead.

Use the openqodex skill to review my changes. Do not run init and do not use npx.
Run this exact command instead: /path/to/sandbox/bin/openqodex review --agent
then follow the brief it prints.

This time the reviewer was Claude Code itself, and the verdict was passed with warnings, with three findings.

The critical one was the SQL string. The major one was the discount divisor.

The minor one was the hardcoded credentials. Notice that it rated the secrets lower than we expected, probably because they were the well-known AWS example values.

The skill then stopped and asked “Fix all, or tell me which?” and waited. Claude did not touch the code until we answered, which is the behavior we want from a review tool.

The report page

OpenQodex also writes a report.html file under .openqodex/reviews/. We opened it in a browser.

The page shows the verdict, the size of the change, the reviewer, a blast-radius note and the findings, each tied to a line of code. It also states that the review was done by the coding agent you are using. That honesty is useful when you share the report with a team.

The push hook

The plugin includes a hook that fires on git push. We created a local bare repo as the remote and asked Claude Code to commit and push.

The hook said OpenQodex could not tell what the push sends, and it suggested a review first. The push still completed.

Two details matter here. Claude ran the commit and the push as one combined command, and the config file the tool created sets block_on_severity to nothing by default, so findings warn and never block. We did not test a configured blocking setup, so we cannot say how strict the hook gets once you set a level.

What Gets Sent Where

Review tools read your code, so check the data flow before you install one. OpenQodex’s own skill file lists the details.

Your code goes to the model your login uses, and the reviewer can search the web unless you set reviewer_web: off in ~/.openqodex/config.yaml. Semgrep downloads its rules on each run, and OSV-Scanner sends dependency names and versions to osv.dev when a dependency file changes. The --offline flag skips the four scanners that go online.

Open Code Review in delegate mode keeps the review inside your Claude Code session. If you switch to its review command and configure a provider, your diff goes to that provider instead. Read its docs for that path before using it on private code.

Which One Should You Use?

Our honest take: both caught the same three headline bugs on a tiny change, so this was not a contest of detection.

Open Code Review felt lighter and faster. OpenQodex felt more careful, with its scanners, ranked receipt and report, and it is the one to try if you want a gate on pushes. Neither replaces a human reviewer, and this was one small demo, not a benchmark.

Scanners find known patterns, and a model finds logic slips, so the best review uses both.

Try It Yourself

Make a throwaway git repo, commit a small Python file, then add a change with a string-built SQL query and a wrong formula. Load one plugin at a time with --plugin-dir and use this prompt for the second tool.

Review my uncommitted changes. List each problem with its file and line,
rank them by severity, and do not edit any code until I say which to fix.

Common Mistakes

• Installing a review plugin into your real setup before reading its hooks. Use --plugin-dir first.
• Expecting the scanners to find logic bugs. Our discount bug slipped past every scanner and was found by the model.
• Forgetting that untracked files count. Our preview counted a stray __pycache__ folder, so add a .gitignore first.
• Treating a warning as a block. By default OpenQodex warns and never blocks until you set a threshold.
• Approving every permission prompt without reading it. Read the shell command first.

Pro Tips

• Run ocr delegate preview yourself first to see which files will be reviewed.
• Commit .openqodex/config.yaml so your team shares one set of rules.
• Use --offline with OpenQodex when you do not want dependency names sent to a web service.
• Run a review twice on important changes, since model-based reviews can differ between runs.
• Pair the review with tests. Neither tool ran our code.

Cheat Sheet

Frequently Asked Questions

Is Open Code Review free?

The tool is open source under Apache-2.0. Delegate mode uses your own Claude Code session, so usage counts against your Claude plan. Its direct review command needs a model provider that you set up, and that provider may charge you.

Does OpenQodex need an API key?

Its docs say it needs no key beyond your Claude Code or Codex login. We confirmed that the scanners ran with no key, and that the review itself needed a signed-in Claude Code session.

Can these tools replace human code review?

No. Both found the planted bugs in a small file, but they did not run tests, and the OpenQodex report itself says no review finds everything. Use them as a first pass before a teammate looks.

Are they safe to try?

Read the hooks and commands first, and try them in a throwaway folder. OpenQodex’s plugin runs a hook on git push and starts an MCP server, so it does more than a plain slash command.

Where do I find more plugins like these?

Browse our skills directory for more. For other tested plugins, see our post on the Claude API skill and our Terraform plugin comparison.

Conclusion

Both tools work inside Claude Code and caught the same headline bugs in our test: Open Code Review is the lighter, faster option with no setup beyond one command, while OpenQodex adds real scanners, a ranked report and a push hook that only warned in our run. Try them one at a time in a throwaway repo, read what they run, and keep a human in the loop. The source repos are alibaba/open-code-review and openqodex/openqodex.