Using CodeGraph

CodeGraph is a local knowledge graph of a project's symbols, call edges, and files. One call returns verbatim line-numbered source plus the call paths between symbols and a blast-radius summary — replacing a grep + read loop with a single round-trip. Read this before reaching for CodeGraph so you pick the right call and avoid the mistakes below.

When to reach for it

• "How does X work?" / "Where is X?" / "What happens when X runs?"
• Before editing a symbol: source + callers + blast radius in one call.
• Tracing a flow: name both endpoints in one query (e.g. mutateElement renderScene) — it rides dynamic-dispatch hops (callbacks, re-renders) that grep can't follow.
• Judging impact before a change, or when reviewing risk — not only your own refactors.

When NOT to

• Semantic/conceptual search. It knows structure (calls, imports, definitions), not meaning. "Code similar to X" or "where do we handle billing edge cases?" — reason over results yourself or use plain search.
• Unindexed content. Configs, docs, lockfiles, generated code — use Read/Grep.
• Trivial single-file edits. If you know the exact file and line, editing directly is faster than a graph round-trip.
• Correctness. No type-checking or test-running here — the compiler, tests, and linter still own "is this right?".

Which call answers which question

Which tools you can reach depends on how CodeGraph was set up: the default MCP surface is codegraph_explore alone, other tools are enabled per config, and all of them exist as CLI subcommands (codegraph <command>). Use whichever is available — explore alone answers most questions.

You want	Use	Instead of
Almost anything: how X works, where X is, survey an area	explore	grep + read loop
One symbol's full source + direct callers	node	reading the whole file
"What calls X?" (direct, one hop)	callers	impact
"What does X call?"	callees	reading X and grepping each name
"What depends on X transitively?" (blast radius)	impact	chaining callers by hand
Symbol lookup by name/kind	query	grep
File/module layout of an area	files	ls -R + reading files

node returns a symbol's full source or a file's contents from the index — it is not a substitute for read on files CodeGraph doesn't cover.

CLI-only (not an MCP tool): codegraph affected <files...> — which test files a change touches, without running the suite.

impact vs callers is the common mixup: callers is one hop; impact walks the graph transitively. "What could break?" → impact.

Gotchas

Don't re-verify what CodeGraph returned — but do fill gaps

Its results come from a full AST parse, so re-grepping the same symbols is slower and blinder (grep misses dynamic dispatch) — don't double-check what it gave you. It is not infallible, though: a blast radius may be truncated (+N more), and a symbol you expected may be missing. When you need more than it returned, fall back to grep/read for that gap — without discarding the parts it did provide. (The one case where its output itself is suspect: the staleness banner, below.)

Don't over-call on small tasks

One explore usually answers the whole question — treat what it returns as already read. If the first call answered it, stop. Calling before every minor edit just burns tokens.

The staleness banner is per-file

"⚠️ Some files referenced below were edited since the last index sync…" — only the listed files are stale; Read those directly and keep trusting the graph for the rest. The rarer "auto-sync is DISABLED" banner means the whole index is frozen — Read directly until it's resolved.

Same-named symbols

A bare name that exists in several places returns every match. Disambiguate with a file path or a neighboring symbol rather than taking the first result.

Not indexed? Stop calling it

If a tool reports no .codegraph/ for a project, stop calling CodeGraph there for the rest of the session and use built-in tools. Indexing is the user's decision — mention codegraph init if it comes up, but don't run it yourself.