How to give GitHub Copilot codebase context that persists

GitHub Copilot's agent mode explores your repo the way every coding agent does: search for strings, open the matching files, read them into the context window. It answers the question in front of it, but the understanding it built doesn't survive the chat — and the next structural question starts the whole loop again.

Because Copilot speaks the open MCP protocol for external tools, you can hand it something better than search: a persistent, on-device knowledge graph of your codebase. Graphify builds the graph locally — your code never leaves your machine — and registers itself as an MCP server Copilot can call. Setup is three commands.

Step 1: install Graphify

uv tool install graphifyy installs the open-source (MIT) CLI. Code parsing is fully local with no telemetry; the only optional network call is the model used to ingest non-code sources — Claude, OpenAI, Gemini, DeepSeek, Kimi, Bedrock, Azure, or Ollama if you want the entire pipeline on your machine.

Step 2: connect it to Copilot

Run graphify install. It detects GitHub Copilot and registers Graphify's MCP server — eight tools for querying structure, tracing paths, and explaining nodes — so Copilot's agent can call the graph during a conversation the same way it calls its other tools. Copilot's own MCP support is covered in GitHub's Copilot documentation; the Graphify side is on the Copilot integration page. And because Graphify wires into 17 assistants through the same mechanism, the graph you build here also works everywhere else you code — the full list is on the integrations page.

Step 3: map the repo

Run /graphify . as a skill inside an assistant session, or use the CLI equivalent. Tree-sitter extracts the code structure locally across 36 languages — those edges are tagged EXTRACTED, straight from the AST, with no model involved in reading your source. Docs, SQL, schemas, and Terraform are read in by your model and tagged INFERRED; evidence that can't be fully resolved is kept and tagged AMBIGUOUS rather than dropped or presented as fact. That three-way distinction is the graph's honesty guarantee: when Copilot answers from it, you can see at a glance which parts of the answer were found and which were inferred.

You end up with three files in the repo: an interactive graph.html map you can explore in a browser, a written GRAPH_REPORT.md brief covering the god nodes everything depends on and the communities that correspond to real subsystems, and the raw graph.json for anything downstream.

What changes in practice

Ask Copilot what calls a function, what a schema change would break, or how two services connect, and the agent traverses the graph instead of launching a search-and-read loop. Answers come back as paths through real files, each edge labeled with how it was established — and because the graph persists between chats, the discovery cost is paid once, not per session. Token savings vary by repo and question; the one number floating around — 71.5× fewer tokens — comes from a single community user's workload and should be read as exactly that, not a benchmark.

You can query the same graph from the shell with graphify query, graphify path, and graphify explain — useful for checking what Copilot will see before you ask it anything. The docs cover every command, and re-running /graphify . after significant changes keeps the map current.

None of this requires trusting a hosted index with your source. The graph is a set of files in your repo, built by a parser on your machine, and Copilot reads it the way it reads any other tool result — which is the whole point: persistent context without a new place your code has to live.