Code graph
The review agent’s search_code tool does text matching. That’s often enough — but some questions are structural, not textual: Who actually calls this function? What’s the blast radius of changing this signature? Which files import the one I’m editing? inline answers those exactly by building a commit-anchored code-graph index.
It is strictly additive. When an index exists, the reviewer gains four graph tools and a dependency-closure summary. When one doesn’t — not built yet, disabled, or not configured — the review runs byte-for-byte identical to the pre-codegraph pipeline, falling back to live grep. A graph is never a dependency.
# What the index is
A per-commit index holding a semantic graph of a repo’s default branch: nodes and edges, queryable structurally.
- Node kinds: File, Folder, Package, Function, Method, Class, Interface, Enum, Type, Module, Route, Variable, Field, Constant, Decorator, and more.
- Edge types: calls, async calls, HTTP calls, usage, imports, uses-type, implements, inherits, defines, and file containment.
It’s built by a deterministic parsing engine — zero AI tokens. The only cost is a small amount of sandbox compute per build.
# How it’s built
Index builds run in an isolated sandbox:
- Clone the repo at the exact commit — incrementally when a warm sandbox already has the history (re-parsing only changed files), else a cold clone.
- Parse the codebase into the graph.
- Compress and store the graph, plus a precomputed 3D layout.
- Mark the index ready, then prune to the most recent few per repo.
Builds are triggered by a push to the default branch (debounced), by enabling a repo, or by a manual force button. Live progress streams to the portal (queued → cloning → indexing → layout → uploading → ready), and the portal shows a “Rebuilding” strip that refreshes when the build completes.
# How reviews use it
At review time inline resolves the PR head to the nearest ready indexed ancestor on the default branch, then overlays the PR’s own changes:
- If the head is exactly an indexed commit, no overlay is needed.
- Otherwise it compares the index commit to the head and marks the changed files as an overlay — graph answers touching those files are flagged as possibly stale, since the index predates the edit.
- If the comparison is too large or the branch diverged, the whole result is flagged stale but still offered.
The overlay is always unioned with the PR’s changed files, and every step is guarded — any failure just drops back to grep.
# The graph tools
| Tool | Question it answers |
|---|---|
graph_find_definition |
Where is this symbol defined? |
graph_find_references |
Everything that calls or imports this symbol (catches re-exports and renamed imports). |
graph_who_imports |
Which files import this file? (blast radius) |
graph_trace_calls |
Walk the call graph — callers or callees, to a bounded depth. |
Results are prefixed with a staleness header when relevant, and rows touching overlay files get a ⚠ marker so the model weighs them accordingly.
# The dependency-closure section
Beyond tools, inline injects a dependency closure into the review prompt: for the changed files, the set of files that import them. This tells the reviewer up front what a change might ripple into, without it having to ask.
# The 3D graph explorer
Every index also powers an interactive explorer at Repositories → (repo) → Graph: a 3D scene of the codebase as a cloud of nodes (colored by kind, brighter with degree) and edges (colored by type), laid out by a deterministic force pass computed at index time.
There’s also an “Ask the graph” assistant — a streaming Q&A, powered by Claude, that answers structural questions about the codebase and highlights the relevant nodes as it reasons.
# Configuration
Code graph is off unless enabled. Turn it on per repo with the Code graph setting in review config (follows the workspace default when unset). You can also tune how many indexes are retained per repo and how often auto-rebuilds run.