How to give Claude Code codebase memory

Claude Code is very good at exploring a codebase — and that's exactly the problem. Every session, it explores. It greps for symbols, opens the files that match, reads them into context, and rebuilds its mental model of your architecture from zero. Close the session and all of that understanding evaporates. Tomorrow it greps again, reads the same files again, and pays for the same tokens again.

The fix isn't a smarter search; it's persistent structure. Graphify maps your repository into an on-device knowledge graph — functions, classes, config, docs as nodes; calls, imports, references as typed edges — that Claude Code queries instead of grepping. The graph is built once, lives on your machine, and survives every session. Here's the whole setup.

Step 1: install the CLI

Graphify ships as a Python package. Install it with uv: uv tool install graphifyy. That gives you the graphify command globally. The project is open source under MIT, everything runs on-device, and there's no telemetry — the only time anything leaves your machine is if you point the non-code ingestion step at a hosted model, and even that can stay local with Ollama.

Step 2: wire it into Claude Code

Run graphify install. It detects Claude Code (along with any other assistants you use — it supports 17, listed on the integrations page) and wires in two things: the /graphify skill, so you can invoke mapping as a slash command inside a session, and the MCP server, which exposes eight graph tools Claude Code can call natively. No config files to hand-edit.

Step 3: map the repo

In your next Claude Code session, type /graphify . — or run it from the shell if you prefer. Graphify parses your code locally with tree-sitter (real AST extraction, 36 languages, no model call needed to read your source) and uses your model to fold in the non-code material: READMEs, PDFs, SQL, Postgres schemas, Terraform.

A few minutes later you have three local files. graph.html is an interactive map of the codebase you can explore in a browser. GRAPH_REPORT.md is the written brief — the god nodes everything depends on, the communities that correspond to real subsystems, the surprising connections, and suggested questions worth asking. graph.json is the raw structure.

Step 4: ask, don't grep

From here, Claude Code has a fundamentally different move available. When it needs to know what calls a function, what breaks if a schema changes, or how the billing service reaches the auth client, it calls a graph tool over MCP instead of launching a grep-and-read loop. You can use the same tools yourself: 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.

Every edge in those answers carries a confidence tag — EXTRACTED if the parser found it in the AST, INFERRED if the model connected the dots, AMBIGUOUS if the evidence couldn't be fully resolved — so you always know what was found versus what was guessed. The concepts page covers why that provenance model matters.

What actually changes

Two things, in practice. First, answers to structural questions stop being reconstructions and start being traversals — the answer arrives with its path, and every node on the path is a real file. Second, context stops being spent on re-reading. A graph answer is a handful of nodes and edges, not the full text of every file that matched a string. Savings depend on your repo and your questions — one community user reported 71.5× fewer tokens on their workload, a community-reported figure rather than a benchmark, but the direction is the point.

When the code changes meaningfully, re-run /graphify . to refresh the map. The full command reference and MCP details are in the docs.