How do I use Qodo CLI in CI or pre-commit to run automated review checks on every PR?

Quick Answer: You use Qodo CLI in CI and pre-commit by wiring it into your existing pipelines as a “review-first” gate: run qodo against the diff or branch, let review agents scan for logic gaps, missing tests, and compliance violations, and then fail the job if high-severity issues are found. The result is automated, high-signal review checks on every PR—before a human ever opens it.

Why This Matters

AI-assisted development has made it trivial to open more pull requests, faster. What hasn’t scaled is review capacity and governance. Late-stage PR reviews turn into bottlenecks, “LGTM” culture lets critical issues and missing tests slip through, and cross-repo breakages show up in production instead of in CI.

Running Qodo CLI in CI or as a pre-commit hook shifts that review layer left. Every change—whether it comes from a senior engineer or an AI copilot—gets a consistent, multi-repo-aware review before it reaches your main branches.

Key Benefits:

Consistent, automated review on every change: Qodo’s review agents run the same checks on every PR, so standards don’t depend on who’s on rotation.
Catch issues before they reach the repo: Pre-commit + CI usage turns “I hope someone notices this in review” into “the pipeline blocks it by default.”
Built-in governance and compliance: Enforce organization-specific rules, architecture constraints, and traceability checks automatically, not via tribal knowledge.

Core Concepts & Key Points

Concept	Definition	Why it's important
Review-first Qodo CLI	Command-line interface that runs Qodo’s agentic review workflows on local diffs or branches.	Makes Qodo’s review engine available anywhere you run scripts: CI, pre-commit, and custom automation.
Shift-left PR checks	Running logic, test, and compliance checks before code is merged (or even committed).	Reduces PR backlog, shortens review cycles, and catches critical issues before they become expensive to fix.
Living rules + compliance in CI	Centralized rules system and compliance checks enforced as part of your pipeline.	Ensures every PR is validated against the same standards, policies, and traceability requirements across teams and repos.

How It Works (Step-by-Step)

At a high level, integrating Qodo CLI into CI or pre-commit looks like this:

Install and authenticate Qodo CLI
Choose what you want to review (diff, branch, or PR range)
Run the appropriate Qodo review workflows
Parse results and decide when to fail the build
Iterate on rules and severity thresholds as you scale

Below is a more concrete walkthrough.

1. Install Qodo CLI in your environment

In CI, you usually install Qodo CLI as part of your pipeline setup step. For pre-commit, you install it once on developer machines (often via your internal tooling docs).

Typical patterns:

CI (Linux runner):

# Example: download & install Qodo CLI
curl -L https://cli.qodo.ai/install.sh | bash

# Or if distributed internally:
chmod +x ./qodo
sudo mv ./qodo /usr/local/bin/qodo

Local / pre-commit (developer machine):

# Use your internal distribution or the same install script
curl -L https://cli.qodo.ai/install.sh | bash

Adjust the exact command to match your actual Qodo CLI distribution (internal registry, package manager, etc.).

2. Authenticate Qodo CLI

The CLI needs an API key or token so it can access Qodo’s Context Engine and your organization’s rules.

Common patterns:

CI environment variable:

export QODO_API_TOKEN=${{ secrets.QODO_API_TOKEN }}

Local / pre-commit:

export QODO_API_TOKEN=your_local_dev_token

Or, if your CLI supports a login/config command:

qodo auth login --token "$QODO_API_TOKEN"

The important part is consistency: use environment variables and secrets so tokens never live in your repo.

3. Run Qodo review workflows on the diff

In CI, the CLI typically runs on the PR diff or the compare range between the base and head branch. In pre-commit, it runs on staged changes.

Conceptually, you want Qodo to look at:

The exact changes in the PR, not your entire repo every time.
Multi-repo context via Qodo’s Context Engine, so it can reason about cross-repo impact, shared modules, and organizational patterns—even though you’re only passing in a diff.

Example patterns (pseudo-commands; adapt to your CLI syntax):

Run full review on a PR diff (CI):

# In GitHub Actions, for example:
BASE_SHA="${{ github.event.pull_request.base.sha }}"
HEAD_SHA="${{ github.event.pull_request.head.sha }}"

qodo review --from "$BASE_SHA" --to "$HEAD_SHA" \
  --workflow standard_pr_review \
  --output-format json \
  --output-file qodo-report.json

Run review on staged changes (pre-commit):

# Pre-commit hook script
STAGED_FILES=$(git diff --cached --name-only)

if [ -n "$STAGED_FILES" ]; then
  qodo review --files $STAGED_FILES \
    --workflow local_diff_review \
    --output-format json \
    --output-file qodo-precommit-report.json
fi

Typical workflows you might wire into CI/pre-commit:

standard_pr_review – logic gaps, bugs, missing tests, risky changes.
compliance_review – security, org-specific compliance, traceability.
test_coverage_review – missing or insufficient tests for changes.
docs_review – out-of-date docs, missing changelog entries.

Under the hood, these are Qodo’s 15+ agentic workflows hitting your change set with specialized review agents.

4. Enforce thresholds and fail the build when needed

Qodo is intentionally not all-or-nothing. You can choose what severity of issues should block a PR vs. only warn.

Typical pattern:

Run Qodo CLI and export results to JSON.
Parse the result for:
- Number of high / critical issues.
- Presence of compliance violations.
- Missing tests for impacted areas.
Exit non-zero if thresholds are exceeded.

Example shell snippet:

qodo review --from "$BASE_SHA" --to "$HEAD_SHA" \
  --workflow standard_pr_review \
  --output-format json \
  --output-file qodo-report.json

CRITICAL_COUNT=$(jq '.issues | map(select(.severity == "critical")) | length' qodo-report.json)
HIGH_COUNT=$(jq '.issues | map(select(.severity == "high")) | length' qodo-report.json)

if [ "$CRITICAL_COUNT" -gt 0 ] || [ "$HIGH_COUNT" -gt 0 ]; then
  echo "Qodo found $CRITICAL_COUNT critical and $HIGH_COUNT high severity issues."
  exit 1
fi

You can use a similar pattern for specialized checks:

Fail if /compliance workflow flags any violations.
Fail if test coverage for changed files is below your org threshold.
Warn-only on documentation and style issues.

This is where Qodo becomes a governance layer instead of just another linter: you define the rules, and CI enforces them uniformly.

5. Integrate with your CI provider

The CLI is provider-agnostic, so you plug it into whatever you already use.

GitHub Actions example

name: qodo-review

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  qodo-review:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Qodo CLI
        run: |
          curl -L https://cli.qodo.ai/install.sh | bash

      - name: Run Qodo review
        env:
          QODO_API_TOKEN: ${{ secrets.QODO_API_TOKEN }}
        run: |
          BASE_SHA="${{ github.event.pull_request.base.sha }}"
          HEAD_SHA="${{ github.event.pull_request.head.sha }}"

          qodo review --from "$BASE_SHA" --to "$HEAD_SHA" \
            --workflow standard_pr_review \
            --output-format json \
            --output-file qodo-report.json

          CRITICAL_COUNT=$(jq '.issues | map(select(.severity == "critical")) | length' qodo-report.json)
          HIGH_COUNT=$(jq '.issues | map(select(.severity == "high")) | length' qodo-report.json)

          if [ "$CRITICAL_COUNT" -gt 0 ] || [ "$HIGH_COUNT" -gt 0 ]; then
            echo "Qodo found $CRITICAL_COUNT critical and $HIGH_COUNT high severity issues."
            exit 1
          fi

GitLab CI example

qodo_review:
  image: alpine:latest
  stage: test
  before_script:
    - apk add --no-cache curl jq git
    - curl -L https://cli.qodo.ai/install.sh | sh
  script:
    - export QODO_API_TOKEN="$QODO_API_TOKEN"
    - BASE_SHA="$CI_MERGE_REQUEST_TARGET_BRANCH_SHA"
    - HEAD_SHA="$CI_MERGE_REQUEST_SOURCE_BRANCH_SHA"
    - qodo review --from "$BASE_SHA" --to "$HEAD_SHA" \
        --workflow standard_pr_review \
        --output-format json \
        --output-file qodo-report.json
    - CRITICAL_COUNT=$(jq '.issues | map(select(.severity == "critical")) | length' qodo-report.json)
    - HIGH_COUNT=$(jq '.issues | map(select(.severity == "high")) | length' qodo-report.json)
    - |
      if [ "$CRITICAL_COUNT" -gt 0 ] || [ "$HIGH_COUNT" -gt 0 ]; then
        echo "Qodo found $CRITICAL_COUNT critical and $HIGH_COUNT high severity issues."
        exit 1
      fi
  only:
    - merge_requests

The same pattern applies to Bitbucket Pipelines, Azure DevOps, Jenkins, and others: install CLI, authenticate, run reviews, enforce thresholds.

6. Wire Qodo into pre-commit hooks

Pre-commit is where you get the maximum “before commit” benefit: developers see Qodo’s findings while they still have full context in their IDE.

A simple pre-commit hook (using the standard .git/hooks/pre-commit pattern):

#!/bin/sh
# .git/hooks/pre-commit

STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)

if [ -z "$STAGED_FILES" ]; then
  exit 0
fi

# Ensure Qodo is available
if ! command -v qodo >/dev/null 2>&1; then
  echo "Qodo CLI not found; skipping Qodo review."
  exit 0
fi

echo "Running Qodo review on staged changes..."

qodo review --files $STAGED_FILES \
  --workflow local_diff_review \
  --output-format json \
  --output-file qodo-precommit-report.json

CRITICAL_COUNT=$(jq '.issues | map(select(.severity == "critical")) | length' qodo-precommit-report.json)
HIGH_COUNT=$(jq '.issues | map(select(.severity == "high")) | length' qodo-precommit-report.json)

if [ "$CRITICAL_COUNT" -gt 0 ] || [ "$HIGH_COUNT" -gt 0 ]; then
  echo "Qodo found $CRITICAL_COUNT critical and $HIGH_COUNT high severity issues in staged changes."
  echo "Fix issues or explicitly override before committing."
  exit 1
fi

You can refine this over time:

Only run on certain paths (e.g., src/, services/).
Run specialized workflows (e.g., /improve for refactors).
Add a mechanism for local overrides with a commit trailer (e.g., qodo-override: true) that you still track in CI.

Common Mistakes to Avoid

Treating Qodo CLI like a generic linter: Qodo isn’t just style checks. If you only wire it in to replace ESLint, you’re missing its real value: multi-repo context, logic gaps, cross-service breakages, and compliance enforcement. Use the workflows that actually reflect your risk profile.
Failing builds on every minor suggestion: If you block merges on low-severity findings, developers will either fight the tool or tune it out. Start by failing on critical/high issues and compliance violations, and keep informational or style issues as warnings or IDE-only feedback.

Real-World Example

A fintech team with ~100 engineers and dozens of microservices had a persistent PR backlog: reviews took 1–3 days, and incidents often traced back to cross-service changes that “looked fine” in single-file diff reviews. They already used AI copilots heavily, which increased throughput but also surfaced more late-stage review problems.

They integrated Qodo CLI into their CI:

Every PR triggered a standard_pr_review workflow.
CI failed if Qodo found any critical/high issues or compliance violations (e.g., missing ticket traceability tags).
Qodo’s Context Engine gave the review agents full multi-repo context, so they caught breaking changes across shared modules and services that static diff review missed.
They later added a pre-commit hook for local diff review and test generation suggestions.

Within a few weeks:

PR review time dropped because humans started from a review-ready queue with issues already surfaced and suggested fixes in place.
Cross-repo breakages dropped significantly; Qodo flagged them in CI before merges.
Compliance and security teams no longer had to manually check every PR for traceability and policy adherence—the CLI enforced it.

Pro Tip: Start by running Qodo CLI in non-blocking mode in CI for a sprint or two. Collect data on what it flags, tune your rules and thresholds based on real findings, and only then turn on “fail on high/critical” to avoid surprising the team.

Summary

Using Qodo CLI in CI or pre-commit turns code review from an ad-hoc, human-only gate into a consistent, agentic quality system that runs on every PR. Instead of relying on late-stage “LGTM” checks, you:

Run multi-repo-aware review agents on every change.
Enforce your living rules system and compliance policies automatically.
Catch logic gaps, missing tests, and cross-repo breakages before they hit main branches.

Qodo isn’t perfect, and you should still verify tests and automated fixes—but with Qodo CLI wired into your pipelines, humans review less noise and focus on higher-order design and risk.

Next Step

Get Started