OpenQodex: Open Source AI Code Review Before Push for Claude Code and Codex

AI coding agents have raised the speed at which code is written, but they have not raised the speed at which it is reviewed. Diffs grow larger, human attention wears thin, and the few lines that actually matter hide inside a pile of plausible-looking changes. OpenQodex takes a plain approach to this problem: move the review to before the push, so it becomes the last gate a change passes before it leaves your machine. It targets Claude Code and Codex, and it also runs straight from the terminal. The core is one command, openqodex review. It first works out what you actually changed: the commits not yet pushed, plus everything uncommitted. It then runs the scanners that fit the changed files and keeps only the findings that fall on lines you touched, so the historical debt in old code does not pull you off course. Scanner output is only raw material. OpenQodex next starts its own reviewer, a separate Claude Code or Codex process that reads a frozen copy of the change. That reviewer must check every scanner finding, and it is given every changed line. Its answer is not taken on trust: OpenQodex checks it with scripts and then assembles one report. The point of this design is the division of labour. Rule-based scanners find patterns in a stable, repeatable way, but they raise many false alarms and understand no context. Language models understand intent and context, but they can miss things or invent them. Letting the model rule on every scanner finding, and then letting deterministic scripts check the model's conclusions, creates three layers that restrain one another. That is more credible than leaning on any single layer.

The degree of isolation around the reviewer is the part of this project that deserves the closest reading. According to the README, when Claude Code is the reviewer it starts with read, search and list tools only, inside the copy of the change, with none of your settings, hooks, plugins, memory or instruction files. Its event stream shows every read, so the report can list the files it read. Codex differs slightly. It starts in a read-only sandbox that confines reads to the copy of the change and the system folders, with no network for its commands, and with none of your config, plugins, hooks or the repository's instruction files. The documentation is also frank about two limits: Codex still loads the global ~/.codex/AGENTS.md, and its event stream does not show every command, so the report states that its reads were not recorded. Writing such boundaries into the documentation is more reassuring than claiming absolute safety, and it invites each user to weigh them against their own threat model. Completeness has a precise definition here. A review is complete only when three things hold: every stage ran, every scanner finding was either raised or dropped with a reason, and every changed line was in front of the reviewer. That can mean in the brief, in a later message from OpenQodex, or, for Claude Code, in a file it read. If any condition fails, the tool prints "Review incomplete" instead of a tidy verdict. In effect, coverage stops being a slogan and becomes a checkable condition. For teams used to vague approvals, this is a practice worth borrowing. The output is equally restrained. When the run ends, the terminal prints a short receipt: the verdict, the reviewer's summary, one line per finding (number, severity, category, title, file and line) and the absolute paths of report.html and report.md. The full report is also written to disk as HTML, Markdown, JSON and SARIF, and the SARIF file makes it easy to feed existing security tooling. The file report.html is a single file on your disk. It shows each changed file as a diff, each finding under its line, and then the coverage, the scanners and the blast radius. According to the README it runs no script, loads nothing from outside, escapes every string, and redacts the secrets the scanners found. The decision to fix stays with the human. The bundled skill tells the agent to show you the receipt, ask "Fix all, or tell me which?", and fix only the findings you name. The command openqodex findings 1,3 prints the named findings in full.

Adoption cost is low. The command npx openqodex init looks for Claude Code, Cursor, Codex CLI and Cline on your machine, prints every file it will write, and asks once. It then names the reviewer it found, or what you need to fix. It needs Node 22 or newer and git, runs on macOS and Linux, and asks Windows users to use WSL. Beyond a logged-in Claude Code or Codex, it needs no other key, account or server. Besides the default local change, review --all covers the whole repository, and review followed by a branch name or a pull request number such as '#42' covers work that is not your current checkout: OpenQodex fetches it, checks it out in a temporary folder and reviews what it added since it left its base. The current release is 0.12.0 under the Apache-2.0 licence. Day-to-day, this changes the shape of the workflow. Most code review happens after a pull request is opened, when the reviewer faces a finished commit history and the author's context has already scattered. Moving review to before the push means problems surface at the cheapest moment: the change is still local, the author remembers the reasoning, and no colleague is interrupted by the fix. Because every scanner result is limited to lines you changed, each finding in the report bears on what you are doing right now, and you do not dig through inherited issues. For teams where agents produce code in bulk, this adds a cheap and dependable gate between committing and sharing. It also lets human reviewers save their attention for architecture and business judgement, which machines still handle poorly.

From an industry view, OpenQodex stands for a pattern that is taking shape: review is no longer a step after merge but a local, auditable step inside the agent workflow. Some caution is due. A model from the same family reviewing code written by a similar model may share blind spots. The Codex path is clearly less auditable than the Claude Code path. And a 0.12.0 version number signals an early project. This analysis rests on a public README excerpt, and we make no claims about parts it does not cover. Still, the project builds three ideas into the skeleton of the product: evidence, coverage, and a human who decides. Every team that connects agents to daily development should take those three ideas seriously.