​

PR review

Qodex reviews pull requests on linked GitHub repos and merge requests on linked GitLab.com projects. When a change request opens or changes, Qodex reads the diff, looks for real bugs and security issues, posts a walkthrough comment, adds inline findings where it can, and checks the preview deployment when available. GitHub reviews also update a GitHub Check Run.

​

What Qodex adds to a PR

​

Review flow

A GitHub pull-request webhook, GitLab merge-request webhook, supported Qodex mention, or the Run review button in Qodex starts the review. Qodex fetches the change-request diff through the linked source-control connection, reads .qodex.yaml, loads project context, and reviews the diff with a high-precision confidence floor. Findings below 0.7 confidence are dropped before they reach the PR. Repo rules such as severity thresholds and excluded paths are applied next. Findings on changed lines become inline comments. Findings outside the diff move into the walkthrough body so they are still visible. If the PR has a successful preview deployment, Qodex can run safe verification probes and attach request and response evidence. At the end, Qodex posts the review and records the findings. For GitHub, it also completes the Check Run as neutral, success, or failure depending on the repo’s gate policy.

​

Deeper review on larger PRs

For larger or riskier pull requests, Qodex can spend extra review attention where it is most useful: real bugs, missing tests, risky behavior changes, and security issues. The goal is still the same: fewer low-value comments, more findings that explain a real risk. Repo settings and .qodex.yaml decide which paths, severities, and confidence levels should reach the PR.

​

The PR review page

In your project, open Code > PR review in the sidebar. The page has a Repository selector and a Period selector at the top, and three tabs:

• Overview: what Qodex reviewed and found in the selected period. Tiles show pull requests reviewed, Findings posted, Acted on (resolved by the team or fixed on a later push), Dismissed, and Time to first review (the median wait from the PR being opened, pushed to, or someone asking for a review, to Qodex posting it). Below the tiles are the split between on-request and automatic reviews, reviews and findings over time, findings by category and by severity, and a breakdown by author.
• Pull requests: every tracked PR with its state, author, review status, and finding counts. Filter by Status or Author, or search by title, repo, branch, or author. The toolbar shows how many pull requests the month has used against the project’s plan. Click a row to open its review record.
• Settings: review settings for the repository chosen in the Repository selector.

For a project whose linked repos are all on GitLab, the page says merge requests instead of pull requests. The Period selector offers calendar months (UTC) and All time. The Overview also offers Last 3 months and Last 12 months.

​

A PR’s review record

Click a pull request to open its record. The header links to the PR on GitHub or GitLab and has a Run review button (Review again after the first review) for open PRs. Below it are tiles for findings, security findings, open findings, and reviews, then the review Summary, the Findings (filter by Open, Acted on, or Dismissed), and the Review history, which shows what started each review, for example a push or a request by a named person, and why a review was skipped. Answers Qodex gave to questions asked on the PR appear under Questions and answers. After a review finishes, Run review waits two minutes before it can run another one. The button shows the time left. When the pull request has used every review its plan includes, the button is disabled and says why.

​

Configure a repo in Qodex

Open the Settings tab on the PR review page and pick the repository in the Repository selector. You can also open Settings > PR review and select the repository there. If a monorepo is linked by folder, the selector lists each folder as its own entry, for example acme/shop (backend): review settings and review context are kept separately for each linked folder. The Pull request tab lets you turn Automatic reviews on or off, choose the minimum severity, place lower-severity style and convention notes in the walkthrough instead of inline threads, configure merge blocking, exclude paths or rules, and limit reviews to particular authors or base branches. With Automatic reviews off, opening or pushing to a PR no longer starts a review, but @qodex-ai review and the Run review button still do. This makes a repository review-on-request. Every review still counts against the plan. Use Commands to see every available PR command. The approval command is off by default; a maintainer must enable it here before @qodex-ai approve can submit a GitHub approval. Review context stores owner-written review guidance and the lessons Qodex has learned from prior PR discussions. .qodex.yaml in the repository takes precedence over the overlapping pull-request settings at review time.

​

Plan usage emails

When a project’s plan includes a set number of pull requests a month, project members get an email when 80% of them are used and another when they are all used. Each email is sent at most once a month and links to the PR review page. See Limits and caveats for how plan limits work.

​

Project-specific learning

Qodex can use resolved findings and reviewer feedback from earlier PRs as project-specific context for future reviews. This helps the reviewer avoid repeating issues the team has already handled and keep useful project rules close to the repo. When there is no learned context yet, the PR review surface explains that clearly so users know the feature is empty because the project has not built review history. For monorepos, link the same repo by project directory so each app or service can keep its own review context.

​

Where to go next

​

When to use it

• Use PR review when you want one reviewer per repo that focuses on real bugs, security issues, and risky behavior changes.
• Use it when you ship several PRs a day and want review status next to CI.
• Use it when linting already catches style problems and you want a reviewer that can also test a preview deployment.

​

When not to use it

• Do not expect Qodex to be a nitpicker. It defaults to severity_threshold: minor and drops findings below confidence: 0.7.
• Docs-only, generated-file, or no-op diffs may produce a clean review or be skipped by repo policy.

​

Related