How to give Claude Code a code knowledge graph (2026 guide)

Claude Code's default way of understanding a repo is exploration: grep, read, repeat. It's genuinely good at it, which hides the cost — every session starts from zero, re-reads the same files, and spends the same tokens rebuilding a mental model that evaporated when yesterday's session ended.

The alternative is to give it structure that persists. A code knowledge graph stores your codebase's actual relationships — calls, imports, definitions, references — as typed edges Claude Code can traverse instead of reconstructing. Graphify builds that graph on your machine and plugs it into Claude Code twice over: as a slash command and as a set of MCP tools. Here's the setup, end to end.

Step 1: install the CLI

uv tool install graphifyy gives you the graphify command globally. It's open source under MIT, runs on-device, and sends nothing anywhere by default — the one optional network dependency is the model used to ingest non-code sources, and even that can stay local with Ollama.

Step 2: run graphify install

graphify install detects Claude Code and wires in both halves of the integration. The /graphify skill lets you trigger mapping as a slash command inside a session. The MCP server exposes eight tools — structural queries, path tracing, node explanations — that Claude Code calls natively, exactly like its built-in tools. Details are on the Claude Code integration page.

If you use other assistants alongside Claude Code, the same command wires them up too — Graphify supports 17 through the same MCP mechanism, so the graph you build once is available everywhere you code.

Step 3: build the graph with /graphify .

In your next session, type /graphify . — Graphify parses your code locally with tree-sitter, a deterministic parser covering 36 languages, so no model call is needed to read your source. Your model of choice folds in the rest: READMEs, PDFs, SQL, Postgres schemas, Terraform.

The output is three local files: an interactive graph.html map, a GRAPH_REPORT.md brief that names the god nodes and the communities that correspond to real subsystems, and the raw graph.json.

Step 4: let it query instead of grep

From here, structural questions stop being archaeology. When Claude Code needs to know what calls a function or what breaks if a schema changes, it calls a graph tool and gets back a path — real files, real symbols, every edge tagged EXTRACTED, INFERRED, or AMBIGUOUS so you can see what was found versus what was guessed. That provenance model is the heart of the design; concepts explains it properly.

The same power is available to you directly: graphify query answers questions over the structure, graphify path traces how two pieces of code connect, and graphify explain walks through why a node matters. Full reference in the docs.

The payoff

Two changes compound. Answers arrive with their evidence instead of being reconstructions, and context stops being burned on re-reading — a graph answer is nodes and edges, not the full text of every file that matched a string. How much that saves depends on your repo; one community user reported 71.5× fewer tokens on their workload, a community-reported number rather than a benchmark, and the honest claim underneath it is simply that traversals send less text than file dumps.

The maintenance story is one habit: re-run /graphify . after major changes so the map stays true to the code. Between refreshes, the graph sits in your repo as plain files — openable, inspectable, and yours.