Open source · Knowledge graph · MCP
It indexes any repository into a graph of dependencies, call chains, functional clusters, and execution flows, then serves that structure to your editor through MCP so agents stop guessing and start reasoning with the real architecture in view.
Notice
The maintainers state that GitNexus has no official token or coin. Any asset using the name on third-party launch platforms is not affiliated with the open-source project. Treat unsolicited token offers as unrelated to the repository’s engineering work.
Overview
Documentation tools summarize files in isolation. GitNexus builds a queryable model of how your system actually fits together, so search, impact analysis, and refactors can follow real edges in the graph instead of brittle keyword matches.
Tree-sitter parsing and graph storage capture relationships across the codebase. Hybrid retrieval combines lexical and semantic signals so agents can jump to the right cluster fast, then drill into symbols and processes with confidence.
Use the Web UI for quick exploration in the browser, or the CLI with MCP for daily work in Cursor, Claude Code, Codex, Windsurf, and OpenCode. Bridge mode lets the UI attach to a local server so you browse CLI-indexed repos without re-uploading.
The CLI path keeps indexes on disk under .gitnexus/ inside each repository and registers them in a local registry. The default Web UI path keeps analysis in-browser with LadybugDB WASM—no mandatory hosted backend for core workflows.
Detect stale indexes after edits, map git diffs to affected processes, and run blast-radius checks before you merge. Optional embeddings trade speed for richer semantic recall when you need it.
Product surfaces
Pick the path that matches how you work. Most teams that pair AI agents with production code start with the CLI and MCP integration, then add the Web UI when they want a visual map for reviews or demos.
| CLI + MCP | Web UI | |
|---|---|---|
| Purpose | Index locally and connect agents through MCP tools and resources. | Graph explorer plus chat in the browser for rapid orientation. |
| Typical users | Engineers using Cursor, Claude Code, Codex, Windsurf, or OpenCode daily. | Anyone who wants a guided tour without installing tooling first. |
| Scale | Full repositories at the sizes you keep on disk. | Large trees run in-browser within practical memory limits, or unlimited when paired with a local backend. |
| Install | npm install -g gitnexus or use npx for one-off runs. |
No install for the hosted demo; local development follows the README. |
How it works
The pipeline is intentionally boring engineering: parse, normalize, store, expose. That predictability is what makes downstream agent behavior easier to audit than opaque retrieval-only stacks.
Run gitnexus analyze from a repository root. The command walks the codebase with Tree-sitter, builds the graph, can install editor hooks and generated skills, and writes structured context files such as AGENTS.md where appropriate.
Indexes live beside your project while a global registry tracks what is available to the MCP server. One server can serve multiple repositories, so agents list repos, pick a target, and call graph-backed tools without per-project MCP duplication.
Standard tools cover search, symbol context, impact analysis, coordinated rename assistance, Cypher access, and multi-repo group operations. Resources publish summaries of clusters, processes, and schema so models read stable entry points before deeper queries.
After substantive edits, refresh the index so blast-radius and flow queries stay aligned with HEAD. The CLI exposes status and clean commands; integrations such as Claude Code hooks can nudge agents when a stale graph would mislead a review.
GitNexus
# Index from the repository root
npx gitnexus analyze
# One-time editor configuration for MCP
npx gitnexus setupWhy it matters
When agents only see flat files, they recreate architecture in their heads every session. A durable graph gives them the same landmarks your senior engineers use: entry points, hot paths, and the real boundaries between modules.
Impact tooling maps proposed edits to downstream callers and data flows, which reduces surprise breakages when models suggest wide refactors.
README positioning notes that smaller models paired with deep structural context can punch closer to top-tier models that rely on breadth alone—because the environment supplies what raw parameter counts cannot.
Cypher and explicit process traces make it possible to show why a path was flagged, not just that a heuristic fired. That matters for regulated teams and for teaching junior developers alongside automation.
The upstream project also describes enterprise SaaS and self-hosted offerings with PR review automation, auto-updating wikis, scheduled reindexing, and multi-repository graphs—useful when you outgrow a single-repo setup.
FAQ
Not exactly. It can generate wiki-style documentation from the graph, but the core value is the live index and MCP surface that stay aligned with code, not a static export that ages overnight.
The README lists first-class paths for Claude Code, Cursor, Codex, Windsurf, and OpenCode, with varying depth for skills and hooks. Check the compatibility table in the repository for the integration that matches your stack.
Core indexing and graph queries run on CPU-focused workflows documented in the project. Optional embedding generation is heavier; skip it when you want faster iteration and enable it when semantic recall is worth the cost.
Use the GitHub issue tracker on abhigyanpatwari/GitNexus so maintainers can triage alongside releases, security notices, and supply-chain documentation for container images.
Primary sources
This page summarizes public README material. For exact command flags, editor snippets, Docker image names, and version policy, read the sources below.