How to use code-review-graph: Add PR impact analysis to Codex and Claude Code

code-review-graph is a local-first code knowledge graph tool that aims to reduce the problem of repeatedly reading the entire warehouse during AI code review. It uses Tree-sitter to parse functions, classes, imports, calls, inheritance and test relationships, saves the results to the SQLite database within the project, and then provides them to AI programming tools such as Codex, Claude Code, Cursor through MCP, CLI, Skills and hooks.

It’s especially suitable for large repositories, monorepo, and cross-file PRs: when a function changes, the graph can calculate the radius of impact along the calls and dependencies, telling the AI which callers, tests, and execution flows are more worthy of inspection.

Quick conclusion

• Requires Python 3.10 or higher.
• Execute code-review-graph install after installation. The tool will detect the installed AI programming platform and write the corresponding MCP configuration.
• Run code-review-graph build for the first time. After that, you can use update, watch or platform hooks to incrementally maintain the map.
• Data is saved in the project’s .code-review-graph/ by default, and core composition and querying do not require source code to be sent to external services.
• Simple single file modifications do not necessarily save Tokens; cross-file calls, test impacts, and large warehouse reviews can better reflect the value of the map.

Install code-review-graph

It is recommended to use an independent Python tool environment to avoid contaminating project dependencies:

1

pipx install code-review-graph

You can also use pip directly:

1

pip install code-review-graph

After entering the Git repository that needs to be analyzed, execute:

1
2
3

code-review-graph install
code-review-graph build
code-review-graph status

install will detect supported platforms such as Codex, Claude Code, Cursor, Windsurf, Zed, Continue, OpenCode, Gemini CLI, GitHub Copilot, etc. and generate appropriate MCP configuration and platform rules. After completion, you need to restart the editor or AI programming tool.

If you want to configure only one platform, you can specify the name:

1
2
3
4

code-review-graph install --platform codex
code-review-graph install --platform claude-code
code-review-graph install --platform cursor
code-review-graph install --platform gemini-cli

When installing using uvx, pip or pipx, install will try its best to identify the actual entry and generate the corresponding configuration. If MCP fails to start, you should first confirm that it can be run directly in the terminal:

1
2

code-review-graph --help
code-review-graph status

How it narrows down the code review context

The composition process can be simplified to:

1

代码仓库 -> Tree-sitter AST -> SQLite 图谱 -> 影响半径 -> 最小审查文件集

The nodes in the graph include functions, classes, files, and imports, and the edges represent relationships such as calling, inheritance, and test coverage. After PR modifies a file, the tool looks for:

1. Which functions and classes are directly changed;
2. Which callers or dependencies may be affected;
3. Which execution flows pass through these nodes;
4. Whether there are corresponding tests and whether there are any gaps in test coverage;
5. Which files are most worth reading for AI review.

This way, the AI doesn’t have to rely solely on filename searches, nor does it have to scan the entire repository by default. For cross-module calls and unfamiliar code bases, this makes it easier to spot indirect effects than simply throwing a PR diff at the model.

If you want to learn about general code knowledge graph and architecture analysis, you can compare [CodeGraph local code knowledge graph tutorial] (/en/2026/05/23/codegraph-local-code-knowledge-graph-ai-coding-agent/) and [Graphify’s Claude Code graph workflow] (/en/2026/05/21/safishamsi-graphify-ai-code-knowledge-graph/). code-review-graph is positioned more toward change impact, risk scoring, and PR review.

Used in Codex or Claude Code

After completing the installation and composition, you can directly ask the AI assistant for tasks:

1

Build the code review graph for this project

The project also provides 3 commonly used slash commands:

1
2
3

/code-review-graph:build-graph
/code-review-graph:review-delta
/code-review-graph:review-pr

A practical review process is:

1. Confirm that code-review-graph status is normal in the warehouse root directory;
2. Modify the code or switch to the branch to be reviewed;
3. Execute code-review-graph update to update the changed parts;
4. Run review-delta or review-pr in Codex or Claude Code;
5. First look at the influence radius, risk function and test gap, and then let AI read the necessary source code;
6. Finally run the original tests of the project rather than using the graph results as test replacements.

The CLI also provides corresponding daily commands:

1
2
3
4
5
6

code-review-graph build
code-review-graph update
code-review-graph status
code-review-graph watch
code-review-graph detect-changes
code-review-graph visualize

watch is suitable for continuous development; detect-changes is used to analyze current changes; visualize will generate interactive HTML diagrams for easy viewing of code communities, Hubs, Bridges and exception couplings.

Which MCP tool should be called first?

The project provides a variety of MCP query tools. It is not necessary to retrieve the complete map in one go for everyday conversations, it is recommended to start with minimal context:

If the MCP tool does not appear, you can refer to the [MCP tool call failure troubleshooting guide] (/en/2026/07/08/mcp-tool-call-failure-troubleshooting-faq/), focusing on checking the location of the configuration file, whether the command is in the PATH, and whether the working directory and the editor have been restarted.

Keep the map up to date

After the first build, there is no need to rebuild the entire repository each time. Incremental updates can be done manually:

1

code-review-graph update

You can also continue to monitor:

1

code-review-graph watch

With supported platform hooks enabled, incremental updates can be triggered when a file is saved or committed. In the example given in the official README, a project of about 2,900 files can be updated in 2 seconds when only a few changed files are re-parsed, but the actual time still depends on the repository size, language, disk and post-processing capabilities.

If your build file, vendor, or large directory is already tracked by Git, but you don’t want to enter the graph, you can create .code-review-graphignore in the root directory of the repository:

1
2
3
4

generated/**
*.generated.ts
vendor/**
node_modules/**

In Git repositories, the tool defaults to git ls-files as the index range, so files not tracked by Git and excluded by .gitignore are usually not indexed.

Connect to GitHub Action to do PR risk check

code-review-graph can also be run in GitHub Actions. The official README current example is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

name: Code Review Graph

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: tirth8205/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

Action will compose and query locally in the CI Runner, and write the risk function, affected execution flow, and test gaps to the PR. Before formal adoption, you should check the latest Release or README of the warehouse, fix a clear version, and do not copy sample versions that may be out of date for a long time.

If the team just wants to observe the results, they can let the workflow comment first; after confirming that the false positive rate and speed are acceptable, they can then consider enabling fail-on-risk as a merge gate.

How to correctly understand Token saving benchmark

The official English README reports that in issue-by-issue testing of 6 real open source repositories, the median token reduction was approximately 82 times, with a range of approximately 38 to 528 times, relative to the baseline of “reading the entire code corpus”. 528 times comes from a single best sample, which is not a result that ordinary projects can achieve.

Things to note when reading these numbers:

• Full reading of the warehouse is an ideal upper bound. A mature Agent will first search and then read a small number of files;
• For small single file modifications, the edges, influence ranges and structure summaries returned by the graph may be larger than reading the diff directly;
• Some recall benchmarks that affect analysis use ground truth derived from the same graph, which has circularity and should be regarded as an upper bound;
• There is still known room for improvement in search sorting, JavaScript and Go execution flow detection;
• Graph tends to overreport some potentially affected files to reduce the risk of missing dependencies.

So don’t write “up to 528x” into your team cost budget. A more reliable method is to compare the same batch of PRs in your own repository: record the number of files actually read by the AI, context length, false positives, false negatives, and review time.

Troubleshooting common problems

AI cannot see the MCP tool after installation

First check:

1
2

code-review-graph --help
code-review-graph status

Then re-execute the installation of the specified platform and restart the tool:

1

code-review-graph install --platform codex

If installed using a virtual environment, the AI tool may not find the same Python environment when it starts. pipx or uvx are usually more suitable as global CLI entry points.

The graph results do not contain new codes

First run:

1
2

code-review-graph update
code-review-graph status

Also confirm that the new file has been tracked by Git and has not been excluded by .gitignore or .code-review-graphignore. Execute complete build if necessary.

Small PR has more context

This is a fixed overhead caused by graph structure metadata. For modifications that only change one line and have no dependencies, it is faster to read diff directly. You can let the AI ​​call get_minimal_context_tool first, and only expand the full review context when cross-file impacts are found.

How to uninstall safely

Preview the content to be deleted first:

1

code-review-graph uninstall --dry-run

Execute after confirmation:

1

code-review-graph uninstall

If you just want to remove the integration but keep the plot data, use:

1

code-review-graph uninstall --keep-data

Which projects are suitable for

More suitable for:

• Large code bases with lots of cross-file calls;
• monorepo, multi-language warehouse and multi-person collaboration projects;
• Frequently use Codex, Claude Code or Cursor to review PR;
• Need to track callers, test gaps and execution flow;
• Do not want the core code graph to rely on external cloud databases.

It is not necessarily necessary to:

• Small projects with only a few files;
• Mainly review documentation or configuration changes;
• Each modification is limited to a single, independent file;
• The team has no willingness to maintain the index and deal with false positives.

Summary

code-review-graph Adds a layer of continuously updated structural indexing to AI code review. It can help tools such as Codex and Claude Code move from “searching for files that look relevant” to “analyzing the impact of changes along call, dependency and test relationships.”

For practical use, start with a common PR: install, frame, run incremental review, and then compare the results with manual review and real testing. If it can reliably identify cross-file impacts and reduce irrelevant reads, then plugging in a watch, hook, or GitHub Action will make it easier to evaluate the benefits than enabling everything initially.

Project address: tirth8205/code-review-graph