Key Takeaway:
GitNexus turns any GitHub repository or ZIP file into a fully indexed, interactive knowledge graph with a built-in Graph RAG agent — running entirely in your browser or locally via CLI, with no server, no cloud upload, and no API key required for core functionality.
AI coding assistants are only as good as the context they receive. Feed a model a handful of isolated code snippets and it will make confident edits that silently break four other modules downstream. GitNexus was built to solve exactly that problem. It indexes an entire codebase into a persistent knowledge graph — tracking every function call, import chain, class hierarchy, and execution flow — then exposes that graph to AI agents through a set of structured tools that return complete, precomputed answers instead of raw edges and raw guesswork.
The result is a code intelligence layer that works for quick one-off exploration in the browser and for deep, persistent agent integration in editors like Cursor and Claude Code, all without sending a line of source code to an external server.
What Is GitNexus?
GitNexus is an open-source code intelligence engine created by Abhigyan Patwari. Its core premise is simple: parse any repository, build a graph of every relationship inside it, and make that graph queryable by both humans and AI agents. The comparison the project itself draws is instructive — it describes itself as “Like DeepWiki, but deeper.” DeepWiki helps you understand code through natural language descriptions. GitNexus lets you analyze it structurally, because a knowledge graph tracks every dependency and call chain, not just high-level summaries.
The engine supports twelve programming languages: TypeScript, JavaScript, Python, Java, Kotlin, C, C++, C#, Go, Rust, PHP, and Swift. It uses Tree-sitter for AST-level parsing, KuzuDB as an embedded graph database with vector support, and a hybrid search strategy combining BM25 keyword scoring, semantic vector search, and reciprocal rank fusion for retrieval.
The Problem GitNexus Solves
Modern AI coding tools — Cursor, Windsurf, Cline, Roo Code, Claude Code — are powerful, but they do not truly know your codebase structure. When an AI agent edits a function without knowing that 47 other functions depend on its return type, breaking changes ship. The agent is not malicious; it simply lacks the structural context that would make its edits safe.
Traditional Graph RAG approaches give the LLM raw graph edges and hope it explores them thoroughly enough. GitNexus takes a different approach: it precomputes structure at index time — clustering related symbols into functional communities, tracing execution flows from entry points through call chains, and scoring confidence on every relationship. When an agent queries the graph, it receives a complete, structured answer in a single tool call rather than chaining four or five exploratory queries and hoping nothing fell through.
This precomputed relational intelligence also addresses a second problem: model democratization. Because the tools do the heavy structural lifting, smaller and cheaper LLMs gain access to full architectural clarity that would otherwise require a frontier model to reason out from raw files.
A third problem, one that is easy to underestimate, is data privacy. Every cloud-based RAG pipeline creates a trust boundary where proprietary source code must leave the device for embedding and indexing. GitNexus eliminates that boundary entirely. The CLI stores everything locally inside the repository’s own .gitnexus/ directory. The Web UI processes everything inside the browser tab. Neither mode transmits source code to any external service.
Two Ways to Use GitNexus
GitNexus ships in two modes designed for different workflows:
The Web UI at gitnexus.vercel.app requires no installation. Drop in a GitHub repository URL or a ZIP file and the browser handles parsing, embedding, storage, and graph rendering entirely in-tab using WebAssembly builds of Tree-sitter and KuzuDB. It is well-suited for quick exploration, demos, onboarding on an unfamiliar codebase, or any situation where you want answers immediately without touching a terminal. The practical upper limit is approximately 5,000 files before browser memory becomes a constraint.
The CLI combined with an MCP server is the path for daily development. It indexes repositories natively on disk using full Tree-sitter bindings and a persistent KuzuDB database, registers a pointer in a global registry at ~/.gitnexus/, and exposes everything to AI agents via the Model Context Protocol. One MCP server serves every indexed repository simultaneously, with no per-project configuration required after the initial setup.
A bridge mode connects the two: running gitnexus serve starts a local HTTP server that the Web UI auto-detects, allowing you to browse all CLI-indexed repositories visually without re-uploading anything.
Getting Started with the Web UI
No installation is needed. Navigate to gitnexus.vercel.app, drag and drop a ZIP export of any repository, and the indexing pipeline begins immediately in your browser. Once complete, the interface presents an interactive graph rendered with Sigma.js and WebGL, and a chat panel powered by a LangChain ReAct agent that queries the knowledge graph on your behalf.
To run the Web UI locally — for example, to connect it to the CLI backend — clone the repository and start the development server:
git clone https://github.com/abhigyanpatwari/GitNexus.git
cd GitNexus/gitnexus-web
npm install
npm run devThe local instance behaves identically to the hosted version and will auto-detect a running gitnexus serve process on the same machine.
Installing and Using the CLI
Installing GitNexus and Indexing a Repository
The CLI is distributed on npm. Install it globally with a single command:
npm install -g gitnexusTo index a repository, navigate to its root directory and run:
npx gitnexus analyzeThis single command walks the file tree, parses every supported source file into an AST, resolves imports and call references across files, clusters related symbols into functional communities, traces execution flows from entry points, and builds a hybrid search index. It also creates AGENTS.md and CLAUDE.md context files at the repository root, giving any AI agent an immediate architectural overview without querying the graph.
To update a stale index after code changes, run gitnexus analyze again. To force a complete rebuild from scratch, use gitnexus analyze --force. To skip embedding generation for a faster initial index, use gitnexus analyze --skip-embeddings.
Configuring MCP for Your Editor
After indexing, configure the MCP server for your preferred editor. The auto-detection command handles most common editors in one step:
npx gitnexus setupThis writes the correct global MCP configuration for Claude Code, Cursor, Windsurf, and OpenCode — whichever editors the command detects on your system. You only run it once.
For Cursor, the resulting ~/.cursor/mcp.json entry looks like this:
{
"mcpServers": {
"gitnexus": {
"command": "npx",
"args": ["-y", "gitnexus@latest", "mcp"]
}
}
}Claude Code receives the deepest integration: MCP tools, agent skills installed to .claude/skills/, and PreToolUse hooks that automatically enrich grep, glob, and bash calls with knowledge graph context before they execute. Smaller editors like Windsurf receive MCP tool access without the skills and hooks layer.
What Your AI Agent Gets
Once configured, every AI agent working in an indexed repository has access to seven structured MCP tools:
query— Hybrid BM25 and semantic search across the graph, results grouped by execution processcontext— A 360-degree view of any symbol: every caller, every callee, every process it participates in, categorized and rankedimpact— Blast-radius analysis showing what breaks at each dependency depth if a given symbol changes, with confidence scoresdetect_changes— Maps a git diff to the execution processes and symbols affected, producing a pre-commit risk reportrename— A coordinated multi-file rename that uses both graph edges and text search to find every reference, with a dry-run optioncypher— Raw Cypher graph queries against the KuzuDB instance for custom structural analysislist_repos— Discovers all repositories currently indexed in the global registry
Agents also receive four pre-installed skills for guided workflows: navigating unfamiliar code, tracing bugs through call chains, analyzing blast radius before changes, and planning safe refactors using the dependency map.
Practical Example: Impact Analysis Before a Refactor
Before modifying a shared service, an agent can call the impact tool to understand the full downstream consequence:
impact({ target: "UserService", direction: "upstream", minConfidence: 0.8 })The response groups affected symbols by dependency depth, labels each relationship type (CALLS, IMPORTS, EXTENDS), and flags which will break immediately versus which are likely affected. A developer reviewing this output before merging a pull request has a concrete, verifiable list of what to test — produced in a single query rather than a manual audit across dozens of files.
Wiki generation extends this structural intelligence into documentation. Running gitnexus wiki reads the indexed graph, groups files into logical modules, and generates per-module documentation pages with a cross-referenced overview — all without manually writing a single architecture document.
Tech Stack
GitNexus is built on a deliberate set of components chosen for their ability to run both natively and inside a browser:
- Parsing: Tree-sitter (native bindings for CLI, WASM for browser)
- Graph database: KuzuDB (native for CLI, WASM for browser), with Cypher as the query language
- Embeddings: HuggingFace Transformers.js with GPU and CPU fallback
- Search: BM25 + semantic vector search + reciprocal rank fusion
- Clustering: Graphology community detection algorithms
- Visualization: Sigma.js with WebGL rendering and the Graphology data layer
- Agent interface: MCP (stdio) for CLI, LangChain ReAct agent for the Web UI
- Frontend: React 18, TypeScript, Vite, and Tailwind CSS v4
Who Should Use GitNexus?
GitNexus is most valuable in three scenarios. First, developers onboarding to an unfamiliar codebase — whether open source or inherited — benefit from an indexed graph they can query in natural language rather than reading file by file. Second, teams using AI coding agents daily will find that connecting those agents to the MCP server measurably reduces the number of missed dependencies and unintended breaking changes. Third, engineers in regulated industries or privacy-sensitive environments get the full benefit of AI-assisted code exploration without transmitting proprietary source code to any external service.
The tool is less suited to monorepos with hundreds of thousands of files, which push against browser memory limits in Web UI mode, and to non-Node.js build environments where the CLI’s npm distribution creates friction. For those cases, the gitnexus serve bridge mode may offer a workable middle ground.
Conclusion
GitNexus occupies a practical and largely uncontested position in the AI developer tooling landscape: it makes the internal structure of a codebase a first-class, queryable asset, available to both humans and AI agents, without any server infrastructure and without any source code leaving the machine. As AI coding agents become more central to daily development workflows, the quality of the context those agents receive will determine the quality of the code they produce. GitNexus directly addresses that context problem.
The project is actively maintained, with incremental indexing, LLM-powered cluster enrichment, and AST decorator detection on the near-term roadmap.
Repository: https://github.com/abhigyanpatwari/GitNexus
Web UI: https://gitnexus.vercel.app/
Community: https://discord.gg/AAsRVT6fGb
