code-review-graph keeps a Tree-sitter map so your AI reviewer reads less

Tree-sitter nodes and edges answer blast radius questions

The repository is parsed into syntax trees with Tree-sitter and stored as a graph: functions, classes, and imports become nodes, while calls, inheritance, and test coverage become edges. At review time the graph is queried for the smallest set of files worth reading. The feature the project headlines is blast-radius analysis. When a file changes, the graph traces every caller, every dependent, and every test that could be affected, and the assistant reads that set instead of scanning the project. Under the hood the edges that make this cheap are the import edges and the call edges, because an incremental update follows exactly those two to find what a change touches. Everything else in the tool, the watch mode, the pre-commit hook, and the MCP server, is a way of keeping that graph close to current.

Quick Start, three commands, then restart the editor

The whole setup is three commands. The first installs the package, from PyPI with pip or with pipx if you prefer an isolated tool. The second writes the integration into whichever editors you actually have. The third parses the codebase into the graph:

pip install code-review-graph          # or: pipx install code-review-graph
code-review-graph install              # detect installed AI coding tools and configure each one
code-review-graph build                # parse the codebase

Python 3.10 or newer is required. Restart the editor or tool afterwards, because the MCP server entry is read at startup. To configure a single platform instead of every one detected, pass --platform with one of codex, claude-code, cursor, windsurf, zed, continue, opencode, antigravity, gemini-cli, qwen, kiro, qoder, copilot, copilot-cli, codebuddy, or hermes:

code-review-graph install --platform cursor
code-review-graph install --platform codebuddy

Config file locations are listed in docs/USAGE.md#supported-platforms. Once the editor is back up, open the project and ask the assistant to build the code review graph for this project.

install writes an MCP entry, hooks, skills, and rules

What install does depends on what it finds, and the choice of command inside the MCP entry is not yours. Inside a Poetry or uv project the entry runs the server through poetry run or uv run. When uvx is on PATH it uses uvx code-review-graph serve. In every other case it falls back to the current Python interpreter. That last branch is the one to think about, because a bare interpreter entry ties the server to whichever environment the editor launches. Alongside the MCP entry, install adds hooks and skills where the platform supports them, and appends graph instructions to the platform's rules file. Files with the project's own entries are what uninstall targets later, and other MCP servers, hooks, skills, and JSONC comments in a shared config are left alone.

uninstall has five flags and a dry-run worth reading first

Removal is as configurable as installation, and the flags are worth reading before you use them. Six variants are documented, from a preview to a full sweep:

code-review-graph uninstall --dry-run    # preview only
code-review-graph uninstall              # preview, confirm, apply
code-review-graph uninstall --yes        # apply without prompting
code-review-graph uninstall --all-repos  # also clean every registered repository
code-review-graph uninstall --keep-data  # remove integrations, keep graph databases
code-review-graph uninstall --keep-user-configs --repo .  # this project only

Scope is what the flags change. The default run touches the Git or SVN working tree you invoke it from and can be run from anywhere inside it. --all-repos extends the cleanup to every repository the tool has registered. --keep-data strips the integrations but leaves the graph databases in place, which matters if you plan to rebuild later. --keep-user-configs paired with --repo. narrows the run to this project. Shared config files are replaced atomically, so a write that fails leaves the original file intact.

A cold build of 3,000 files takes about 40 seconds, then 2.5

Cost of operation splits into two numbers, and only the first one is large. A cold build of a repository of roughly 3,000 files took about 40 seconds, measured on a Django project. After that, hooks and watch mode keep the graph current, and the incremental path is much cheaper. A two-file edit on that same 3,000-file project re-indexes in about 2.5 seconds, of which about 1.4 seconds is process start-up rather than parsing. A no-op update costs only that start-up, which is the number that decides how often you can afford to run a pre-commit hook. The design follows from this. An update diffs the changed files, finds their dependents through the import and call edges, and re-parses only the files whose SHA-256 hash changed, so unchanged files are never touched.

The token claim is one dated capture of one Django project

The whole-codebase-versus-targeted-answer section is where to be careful, because it is where the visible README offers a ratio. In a capture of this repository dated 2026-08-02, at commit 84bde354, 208,821 source tokens became about 3,190 tokens per question. One number in, one number out, and the comparison is between a whole corpus and a slice shaped to the question. The project then qualifies its own figure: the repository has grown a lot since that snapshot, so both numbers are larger today. Treat the reduction as an order of magnitude observed once, not as a property of the tool. If you need a figure for your own repository, docs/REPRODUCING.md is where the measurement procedure is written, and running it yourself is the only way to get a number about your code rather than about this repository's own snapshot.

A parse failure is a partial status, not a hard error

Failure handling for the parser is worth knowing before a large repository disappoints you. When some files fail to parse, the build does not abort. The result carries a status of partial, its summary names the failing files, and the CLI prints a Warning: line on stderr. Those files then keep their previous graph rows, so a file that broke in this build is still represented by the graph entries from the build before it. Language coverage is broad, spanning Python, JavaScript and TypeScript, Go, Rust, Java, C#, Ruby, Kotlin, Swift, PHP, Solidity, Terraform and OpenTofu files, Ansible YAML, Vue and Svelte components, notebooks, and shell scripts. Other YAML files and other .properties files are not treated as source code at all, and Spring Boot config yields key names and value types but never values.

Recent tags, a Beta classifier, and MCP pins with a reason

Maintenance signals are easy to read here. The last push to the repository was on 2026-10-29, and the three most recent tags are v2.3.9 on 2026-09-18, v2.3.8 on 2026-08-21, and v2.3.7 on 2026-07-18, so releases are landing at a monthly cadence rather than in bursts. The pyproject.toml file classifies the project as Development Status :: 4 - Beta, which is the project's own statement about its maturity and the one to weigh against the version numbers. Dependency pins are annotated in the file rather than left bare. fastmcp is held at >=3.2.4,<4, with a comment recording that fastmcp 3.0 broke the server and that the lower bound carries fixes for CVE-2025-62800, CVE-2025-62801, and CVE-2025-66416. anyio is pinned >=4.0,<5 because main.py imports it directly to match the thread limiter FastMCP dispatches synchronous tool bodies through.

Editorial conclusion

code-review-graph suits reviewers who keep hitting token costs on large repositories and who accept that indexing happens on their machine and that the package writes configuration into several editors at once. It does not suit a team unwilling to add a local index of their source, or anyone who wants measured context savings, because the reduction figure in the documentation comes from one dated capture of this repository and the project itself warns the repository has grown since. Before adopting, run code-review-graph uninstall --dry-run from inside the working tree and read the file list, then check docs/USAGE.md#supported-platforms for where the MCP entry landed on your platform. Pin a version rather than tracking main, since the newest tags are v2.3.9 and v2.3.8 and hooks rewrite editor configuration on every install.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes