OpenQodex runs the scanners and then makes a model argue with them

A change is the unpushed commits plus everything uncommitted

The definition of scope is precise, and it is the first thing to understand. OpenQodex reviews your code change before you push it, and your change is the commits you have not pushed plus everything uncommitted. It runs on your machine, from your coding agent or your terminal, which means the review sees your working tree rather than a copy on a server. The tool has no account and no API key of its own. The README also states that OpenQodex itself collects no usage data, that the built-in scanners as OpenQodex runs them send no code, and that the reviewer sends your change to the model service of your Claude Code or Codex login. That distinction is the privacy story of the project, and the README points at a privacy page that lists each network use of the installed version, which is the right thing to read before you wire it into a work repository.

The two stages are the design, not two features

The review runs in sequence. First, OpenQodex runs the scanners that fit the files you changed, and a scanner is a program that checks code without a model, with gitleaks and semgrep given as examples. A finding is one problem at one place in the code, with a severity. The tool keeps the scanner findings on the lines you changed, and it drops findings in test fixtures and in rules you switched off, which is what stops the report from drowning in noise from generated code. Then a reviewer starts, and it is a separate Claude Code or Codex process running on your own login. The reviewer has to raise or drop each scanner finding, with a reason. Scripts check that it answered every scanner finding and that it was given every changed line, so a reviewer that quietly ignores a finding fails the check rather than passing silently. Only then do you choose which findings your agent fixes.

The reviewer is a different process from the one that wrote the code

By default, the agent that wrote the code does not review it, and that separation is the point of the whole design. The tool starts a separate Claude Code or Codex process, and it works because the reviewer is given the changed lines and the scanner findings rather than the previous conversation, so it has no incentive to defend what was just written. The table of where it runs gives the support matrix. Claude Code can start a review, can be the reviewer and can act as a push gate. Codex CLI can do all three, though the push gate only works after you trust the hook in Codex. Cursor and Cline can start a review but cannot be the reviewer, and they have no push gate, so a rule asks those agents to review instead, and the review still needs Claude Code or Codex installed as the reviewer. A push gate is defined as a hook that looks for a review before your agent runs git push.

Installing it writes files, so read what it says it will write

The install is a single command run in your terminal.

npx openqodex init

The init command finds Claude Code, Cursor, Codex CLI and Cline on your machine. It lists the files it will write, asks you once, starts the scanner downloads your repository needs, and then reviews your current change when a reviewer can start. After the install, the launcher script is written to a path outside your PATH, so an npx install leaves no openqodex on your PATH, and you run the review from your own terminal at that path. For agents the same install runs without a question, with a version pin and a host argument.

npx -y [email protected] init --yes --agent <host>

The host values are claude-code, codex, cursor and cline. If you only want the skill and no push gate and no scanner downloads, the skill-only install is a separate command, and a later init replaces that skill with the one init installs.

A review is complete or it is not, and the exit code says which

The tool is unusually strict about partial results. A review is complete only when every stage ran, and otherwise review prints Review incomplete with what is missing, then exits 2. So a non-zero exit is not the same as a failed review, and a script wrapping it has to distinguish the two. The output is four files, report.html, report.md, report.json and report.sarif, and SARIF is the standard JSON format for scanner results, so the findings can be read by other tooling. At the end it prints a receipt holding the verdict, one line per finding and the path of report.html, and the skill instructs the agent to show you that receipt, to ask whether to fix all or to be told which, and to fix only the findings you name. The scope can be widened with review --all, which reviews every file of the repository less the paths that review.paths.exclude leaves out, or narrowed to a branch or a pull request with review <branch> and review '#42'.

The push gate blocks only when you configure it to

Two gates exist and they behave differently. The push gate inside your agent looks for a review of your current work, and it does not know what a push sends, so for a plain git push it asks whether your current work has a passing review, and for any other push command it says it cannot tell. The git pre-push hook that init adds is the precise one, checking the exact commits a push sends, for each git push that runs git hooks, and git push --no-verify skips it. Both warn by default and block only when .openqodex/config.yaml sets review.block_on_severity, with severities running from critical through major, minor and nitpick to info, and a finding at or above the set severity blocks the push. The GitHub Action runs the full review on a pull request when the workflow gives it an Anthropic API key, and without a key it runs the scanners only, as does the pre-commit hook. The offline flag skips the network-using built-in scanners, semgrep, osv-scanner, kubeconform and cargo-deny, and stops scanner downloads, but the reviewer still sends your change to its model service.

Editorial conclusion

OpenQodex suits a developer who already runs static analysis but wants a second opinion that reads the change as a whole, and it suits a team that wants the review to happen inside the agent loop rather than in a separate web interface, since the skill tells the agent to show the receipt and then fix only the findings you name. It is the wrong tool if you want the review to be free, because the reviewer sends your change to the model service of your Claude Code or Codex login, and it is the wrong tool if you cannot install a pre-push hook, since the hook is what checks the exact commits a push sends. Before adopting it, read the privacy page for your version, because the network behaviour differs between the scanners and the reviewer, and check that your repository's languages have their scanners available, since some need a runtime the tool does not install. The last push was on 2026-10-15 and the current release is [email protected] from the same day.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openqodex/openqodex on GitHub
3. Project website
4. README
5. Releases