CGraph writes the same resolved code graph in six shapes: graph.json (the canonical node-link form), graph.html and graph.svg (visual), obsidian.md (a vault), cypher.txt (for graph databases), and call-flow.html (the call graph). Every export is a different lens on one deterministic graph — you pick the shape that matches what you're trying to do with it.
One graph, six exports
When you run the one-shot CLI —
cgraph --root . --out cgraph-out
— CGraph scans the tree, resolves it, and writes all of these into the --out directory (cgraph-out/ by convention). The indexing pipeline lists them at the export stage; the graph model enumerates them precisely:
| Export | Format | What it's for |
|---|---|---|
graph.json | node-link JSON | The canonical graph — everything else derives from it |
graph.html | interactive HTML | Explore the graph in a browser |
graph.svg | vector image | Drop a static picture into a doc or PR |
obsidian.md | Markdown vault | Browse code as linked notes in Obsidian |
cypher.txt | Cypher statements | Load the graph into Neo4j or another Cypher store |
call-flow.html | interactive HTML | The call graph specifically — who calls whom |
That's six formats, written from a single build. Because extraction is deterministic, rebuilding produces byte-stable outputs — which is what makes an exported graph safe to check into a repo or diff across commits in CI.
When to reach for each
graph.json — the source of truth
The graph model calls this "the canonical node-link form." It's what you want any time a program is the consumer: feeding another tool, writing a custom query, computing a diff, or building your own visualization. Every other export is a projection of this file, so if you're unsure which to use, start here — it loses nothing.
graph.html and graph.svg — see it
The two visual exports answer the "show me" questions. graph.html is interactive — open it in a browser and pan around the graph of files, symbols, and the links between them (imports, calls, relations). graph.svg is the static counterpart: a vector image you can embed in a design doc, an architecture review, or a PR description where an interactive page won't render. Same graph, one you explore and one you paste.
obsidian.md — code as a knowledge base
The obsidian.md export writes the graph as an Obsidian vault — Markdown notes with the graph's edges expressed as links between them. This is the export to reach for when you want to live in your codebase's structure rather than glance at it: Obsidian's own graph view and backlink panel become a navigator over your code's real dependency structure. It pairs naturally with CGraph's optional semantic enrichment, where a host can attach documents that describe parts of the code (see the graph model) — those descriptions land as notes alongside the structural ones.
cypher.txt — into a graph database
cypher.txt is a dump of Cypher statements, ready to load into Neo4j or any Cypher-speaking store. Reach for it when six exports aren't enough and you want the full power of a query language over your code: "find every function within three call-hops of the payment module," "list files imported by more than twenty others." CGraph resolves the graph once; Cypher lets you ask open-ended questions of it afterward, in a database built for graph traversal.
call-flow.html — who calls whom
The other exports carry the whole graph — files, symbols, imports, calls, relations. call-flow.html narrows to one relationship: the call graph. The graph model notes the calls come "from raw call resolution, connecting a caller to a callee (the basis of the call-flow export)." When the question is specifically about control flow — tracing execution paths, spotting a function with a surprising number of callers — this is the focused view, without the noise of import and relation edges.
Export or query?
A fair question: if the graph is resolved, why export at all instead of querying the live daemon? The two serve different moments.
The daemon (graphd) and its MCP tools are for interactive questions against a warm graph — an agent or a developer asking "what calls this?" or "what breaks if I change it?" in the loop. Exports are for taking the graph elsewhere: into a browser, a vault, a graph database, a PR, or another program's pipeline. One is a live service; the other is a portable artifact. You'll often use both — query while you work, export when you want to share, archive, or analyze the structure outside CGraph.
Honest limits
Two caveats worth stating. First, every export is a projection of the resolved graph, and resolution is static — the same tradeoff that runs through CGraph. Dynamic dispatch, reflection, and runtime wiring "can't always be resolved from source, so some edges are approximate." A call-flow.html shows the calls CGraph could resolve statically, not every call that happens at runtime. Read the exports as a precise map of the statically resolvable structure.
Second, the visual exports (graph.html, graph.svg, call-flow.html) are only as legible as the graph is small. On a large repository the full graph picture can be dense; that's exactly when the queryable exports — graph.json and cypher.txt — earn their place, because you ask them a narrow question instead of trying to read the whole thing at once.
Try it
Run cgraph --root . --out cgraph-out on a repository you know well and open the exports side by side — the graph.html for a feel, then obsidian.md or cypher.txt if you want to keep working with the structure. The full flag list is in the CLI reference, and if you'd rather gate PRs on the graph than browse it, see deterministic code-graph diffing in CI. The engine is open source at github.com/taylor009/CGraph.