Question 1

How does it handle monorepos, git worktrees, and multiple repos?

Accepted Answer

Monorepos: one graph per repository root is created automatically; only tracked files are indexed, and a .code-review-graphignore file can exclude additional paths. Git worktrees: each worktree is detected as a separate root and gets its own graph; sharing a single database across worktrees at different commits is not supported. Multiple repos: a lightweight registry (stored at ~/.code-review-graph/registry.json) lets MCP clients search across registered projects, and a daemon can watch several repos to keep their graphs updated. Use --repo, --data-dir, or the CRGDATADIR environment variable to customize locations.

Question 2

How big a codebase justifies it?

Accepted Answer

Below a few hundred files the benefit is marginal because an agent can often hold the whole repo in context. Between a few hundred and a few thousand files is the sweet spot: benchmarks on repos ranging from 60 to ~1,100 files show 38×–528× token reductions on whole‑corpus questions. Multi‑thousand‑file repos and monorepos provide the strongest case, as agents cannot read the entire corpus per query and incremental graph updates keep the index fresh with minimal cost. The frequency of multi‑file queries also influences the payoff.

Question 3

How do I verify it is working?

Accepted Answer

1. Ensure the graph file exists and contains nodes/edges; a zero count means the build didn’t run. 2. Run a change and observe the risk summary and Token Savings panel; add --verify to cross‑check token estimates with the cl100kbase tokenizer. 3. In Claude Code, run /mcp and confirm the code‑review‑graph server is connected and its tools are listed. Then ask a structural question (e.g., "what calls parsefile?") and verify the assistant uses query_graph instead of grepping. If any step fails, consult TROUBLESHOOTING.md.

Question 4

Does it phone home?

Accepted Answer

No. There is zero telemetry. The graph is stored locally in a SQLite file inside your repository, and all core operations run entirely on your machine. The only network activity is optional: installing the embeddings extra will download a sentence‑transformers model from HuggingFace, and cloud embedding providers (OpenAI, Google Gemini, MiniMax) will receive only the function signatures you explicitly choose to embed, after you acknowledge the egress warning. Otherwise, your code never leaves the machine.

Question 5

When should I not use it?

Accepted Answer

The README lists several cases: very small repos (a few hundred files) where the overhead of building a graph outweighs the benefits; trivial single‑file changes where the graph response adds more tokens than the raw diff; one‑off questions on a repo you won’t revisit; and flow detection in languages where CRG’s entry‑point detection is less reliable (e.g., JavaScript and Go currently have low recall). In these scenarios, simple agentic search or grepping is usually sufficient.

Question 6

How does it compare to Serena, codegraph, claude-context, and repomix?

Accepted Answer

These tools solve adjacent problems. code-review-graph builds a Tree‑sitter AST into a persistent SQLite graph with review‑focused edges (blast radius, risk‑scored change analysis, test‑gap detection). Serena uses LSP‑backed symbol retrieval and editing, focusing on editing rather than review. codegraph varies by implementation but generally provides AST/call‑graph indexing. claude-context offers chunk‑plus‑embed semantic code search using a vector store, suited for search rather than structural review. repomix packs an entire repo into a single AI‑friendly file without structural queries. Choose the tool based on whether you need precise editing (Serena), semantic search (claude-context), or review‑oriented structural analysis (code‑review‑graph).

Question 7

Why not just grep?

Accepted Answer

Grep works for simple one‑hop questions like "where is parsefile defined?" but struggles with multi‑hop structural queries that require transitive tracing, test‑coverage mapping, or impact‑radius analysis. Each additional hop would require another round of grepping, increasing token usage and handling false positives from overloaded names. CRG answers these with a single graph query, persists the indexed structure in SQLite, and updates incrementally, avoiding repeated scanning and providing queries that have no grep equivalent, such as "which execution paths does this change touch?"

Question 8

Isn't this just RAG?

Accepted Answer

No. RAG splits your code into text chunks, embeds them, and retrieves chunks by similarity to the query. It cannot answer structural questions such as "who calls X" because similarity provides no guarantee of a call relationship. CRG stores structural edges parsed from the AST—calls, imports, inheritance, test coverage—so a query like "who calls login()" is answered by a graph lookup. Embeddings are optional and used only as a hybrid search aid. Benchmarks show CRG achieving 0.909 on multi‑hop retrieval tasks, whereas pure similarity retrieval cannot perform the second hop.

Question 9

How is this different from LSP and language servers?

Accepted Answer

Language servers and code-review-graph (CRG) both build a structural model of your code, but they optimize for different things. LSP is backed by a real compiler frontend, giving type‑aware, semantically precise results such as exact go‑to‑definition, find‑references, live diagnostics, completions, and safe renames. CRG uses a single persistent graph stored in SQLite, parses once with Tree‑sitter, and supports about 35 languages plus notebooks from one process. It provides cross‑language edges, incremental updates, and review‑oriented edges like tests‑for, execution flows, and risk‑scored change analysis that LSP does not model.

Огляд

Ключові функції

Ціни

Кейси використання

Огляд коду

Оцінка ризику

Плюси і мінуси

Плюси

Мінуси

Відгуки

Питання

Постав питання

Альтернативи Мовні здібності