GitNexus vs CodeGraph: choosing a code knowledge graph
GitNexus and CodeGraph give AI coding agents a structural map of a repository. The real differences are freshness, graph depth, interface, scale, and license.
The short answer GitNexus and CodeGraph both parse code with Tree-sitter, store relationships locally, and expose structural context to AI agents through MCP. GitNexus goes deeper on browser visualization, precomputed processes and clusters, arbitrary Cypher, optional embeddings, and multi-repository analysis. CodeGraph emphasizes a graph that stays current while files change, a simpler fixed tool surface, dynamic-dispatch modeling, broad installer support, and an MIT license. For commercial work, licensing and operational fit matter as much as feature depth: GitNexus uses PolyForm Noncommercial terms, while CodeGraph uses MIT.
AI coding agents are good at reading a file and surprisingly easy to confuse about a system. The failure usually appears one level above syntax: a method changes but six callers depend on its return shape; a route handler looks isolated but feeds three clients; a local fix breaks an execution path the agent never reconstructed.
That is why code knowledge graphs matter. Code is already a graph. Functions call functions. Modules import modules. Types inherit from types. Routes bind to handlers. Data shapes cross repository boundaries. A tool that precomputes those relationships can give an agent a structural answer instead of forcing it to rediscover the architecture through a long sequence of grep, glob, and file reads.
The earlier version of this essay focused only on GitNexus running a knowledge graph in the browser. The project has grown well beyond that framing, and the search question has become more useful: GitNexus vs CodeGraph. Both projects solve the same core problem, but they make different operating choices.
What GitNexus does now
GitNexus indexes a repository into a graph of files, symbols, imports, calls, inheritance, clusters, and execution processes. Its CLI and MCP tools can query a symbol's context, trace paths, estimate blast radius, map API routes, inspect changed code, run structural checks, and execute raw Cypher queries. The project describes the CLI plus MCP as its recommended daily-development path.
The browser experience still matters. GitNexus has a Web UI that parses with Tree-sitter WASM, stores the graph in LadybugDB WASM in memory, computes embeddings in the browser, and lets a user explore a visual graph or chat with a repository. The project's current documentation describes that mode as useful for quick exploration and roughly limited to 5,000 files by browser memory. Larger or persistent work belongs in the local CLI/backend path.
Browser mode is no longer the whole GitNexus story. The deleted version said IndexedDB stored the graph and presented the client-side Web UI as the product's primary architecture. Current GitNexus documentation says the Web UI uses LadybugDB WASM in memory, while CLI/MCP uses native persistent local storage and is the recommended workflow.
What CodeGraph optimizes for
CodeGraph is also a local-first, Tree-sitter-based code graph exposed through MCP. Its defining operating choice is freshness. A persistent file watcher updates the graph after changes, so the agent does not have to rely on a manual re-index before it asks about the code it just edited.
CodeGraph deliberately keeps a fixed query surface rather than exposing arbitrary Cypher. Its documentation also emphasizes framework-aware routes and synthesized dynamic relationships such as React re-renders, callbacks, observers, and event emitters. Those connections are difficult to recover from static name matching alone. It has no equivalent of GitNexus's browser graph visualization.
GitNexus vs CodeGraph: the practical differences
The cleanest direct comparison I found is an issue answered by CodeGraph's maintainer. That source is useful because it names tradeoffs instead of pretending one tool wins every category. It is still written by one side of the comparison, so I checked the claims against each project's current repository documentation.
Current project-level differences that affect an operator Graph interface CLI/MCP plus visual Web UI and chat CLI/MCP; no comparable graph browser Freshness model Re-indexing plus hooks that flag stale state Persistent file watcher with incremental sync Graph depth Precomputed processes, communities, Cypher, optional embeddings Structural graph, FTS5, fixed traversal tools Repository scope Multi-repo groups and contract/cross-impact analysis Projects indexed separately and selected with projectPath; no integrated group analysis Dynamic behavior Static call edges plus process/entry-point analysis Explicit synthesizers for several runtime dispatch patterns License PolyForm Noncommercial; commercial terms required MIT
The table is not a benchmark. It is an operating map. Feature lists cannot tell you which parser resolves your framework more accurately, which graph stays useful after two hours of edits, or which tool returns the smallest amount of irrelevant context. Those questions need a test on the repository you actually maintain.
Which one should an AI coding team choose?
Choose GitNexus when the graph itself is a workspace. The visual browser, arbitrary Cypher, named execution processes, clusters, cross-repository impact, and optional semantic layer are valuable when architecture exploration is part of the job. Choose CodeGraph when the daily loop must stay current with little ceremony. Its watcher-first model, bundled installation path, local SQLite graph, and MIT license reduce operational and commercial friction. Test both when correctness matters more than setup time. Pick five architecture questions and five recent changes from your own repository. Compare missed dependencies, stale answers, tool calls, context volume, indexing time, and how often a human has to inspect the raw files anyway.
Licensing is not a footnote. GitNexus's current repository uses PolyForm Noncommercial terms and offers commercial licensing. CodeGraph uses MIT. A personal experiment and a tool embedded in a paid engineering workflow are different decisions, even if the command to install them looks equally simple.
Local-first reduces one trust problem, not every trust problem
Both projects make local operation central to their value. That matters because source code can contain credentials, proprietary algorithms, customer logic, and architecture that a team cannot casually upload to a third-party analysis service. Keeping the index and query layer on the developer's machine removes a large adoption barrier.
Local does not automatically mean safe. An MCP server can still expose more code than the current task requires. A generated index can still contain sensitive names or literals. A browser UI can still retain keys or state in local storage. The agent still needs narrow permissions, an inspectable tool contract, and clear rules for what leaves the machine through the model provider.
That is the same reason I care about memory layers for coding sessions and agent runtimes with narrow permissions. More context only helps when the system can explain where it came from, how fresh it is, and which action it is allowed to influence.
A useful evaluation harness
Index the same clean commit. Record install time, index time, storage, memory, language coverage, and every warning. Do not compare a warm graph with a cold one. Ask architecture questions with known answers. Use route-to-handler paths, callers of a changed type, an event-driven flow, a cross-module dependency, and a framework-specific relationship the team can verify. Make a change and test freshness. Rename a symbol, change a return shape, add a caller, and switch branches. Measure when each graph notices and whether the agent is warned before it answers from stale state. Measure the handoff, not only the answer. Count tool calls, context returned, missed edges, false dependencies, and how much manual file reading remains. The best graph is the one that improves the actual engineering decision.
This is also how I evaluate AI agent frameworks: under the ugly conditions that make the abstraction earn its place. A graph that looks impressive but goes stale silently is a liability. A graph with fewer features that consistently prevents one bad edit can be the better system.
The bigger shift is not GitNexus versus CodeGraph. It is that AI coding agents are getting a structural layer between the model and the repository. Grep will remain useful. File reads will remain necessary. But asking an agent to rebuild architecture from scratch on every task is starting to look as wasteful as asking a developer to forget the codebase after every commit.
Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.