GitNexus: The Zero-Server Code Intelligence Engine

Code Your Agent Can't See Is Where Incidents Happen

Coding agents like Cursor, Claude Code, and Codex are powerful, but they don't truly know your repository's structure. The classic failure: the AI edits UserService.validate(), unaware that 47 functions depend on its return type, and a breaking change ships. GitNexus answers this by indexing the entire codebase into a knowledge graph — every dependency, call chain, functional cluster, and execution flow is precomputed at index time — then exposing it through a set of smart MCP tools so agents get complete context in a single query.

The project describes itself as "the nervous system for agent context." The one-line pitch: like DeepWiki, but deeper — DeepWiki helps you understand code, GitNexus lets you analyze it, because a knowledge graph tracks every real relationship rather than just descriptions. Maintained by Akon Labs under the PolyForm Noncommercial 1.0.0 license (free for personal and open-source use; commercial use via enterprise licensing), the repo was created in August 2025 and had gathered roughly 47k stars at the time of this entry.

Two Commands to Start: CLI + MCP Is the Main Stage

GitNexus ships two ways to use it; the recommended one is CLI + MCP:

# 1. Index your repo (run from repo root)
npx gitnexus analyze

# 2. Connect your editors (one-time, auto-detects Claude Code, Cursor, Codex, ...)
npx gitnexus setup

A single analyze run indexes the codebase, installs agent skills, registers Claude Code hooks, and generates AGENTS.md / CLAUDE.md context files; setup writes the MCP config so editors like Cursor, Claude Code, Antigravity, Codex, Windsurf, OpenCode, CodeBuddy (Tencent), and Qoder (Alibaba) can call the graph. Claude Code and Codex get the deepest integration: MCP tools + agent skills + PreToolUse/PostToolUse hooks that inject graph context before tool calls and detect a stale index after commits. Codex even supports one-command plugin install: codex plugin marketplace add abhigyanpatwari/GitNexus.

The second form factor is the browser-based Web UI (gitnexus.vercel.app): drop in any git repository or ZIP file and get an interactive knowledge graph plus a built-in Graph RAG chat. The whole frontend runs on WASM (Tree-sitter WASM, LadybugDB WASM, in-browser embeddings), so code never leaves your machine; browser mode is limited by memory to roughly 5k-file repos, or you can connect it to a local gitnexus serve backend for large codebases. Docker Compose brings both services up with docker compose up -d — server on port 4747, Web UI on 4173.

Core Innovation: Precomputed Relational Intelligence

Traditional Graph RAG hands the LLM raw graph edges and hopes it explores enough — one question often takes four or five serial queries. GitNexus moves all the structuring work (clustering, tracing, scoring) forward to index time:

flowchart TB
    subgraph Traditional["Traditional Graph RAG"]
        U1["Q: What depends on UserService?"] --> Q1["Query 1: find callers"]
        Q1 --> Q2["Query 2: which files?"]
        Q2 --> Q3["Query 3: filter tests?"]
        Q3 --> OUT1["Answer after 4+ queries"]
    end
    subgraph GN["GitNexus Smart Tools"]
        U2["Q: What depends on UserService?"] --> TOOL["impact UserService upstream"]
        TOOL --> OUT2["1 call: 8 callers, 3 clusters, all 90%+ confidence"]
    end

This "precomputed relational intelligence" buys three things: reliability — context is already inside the tool response, so the LLM can't miss it; token efficiency — no ten-query chains to understand one function; and model democratization — smaller LLMs work because the tools do the heavy lifting.

17 MCP Tools: From Impact Analysis to Taint Tracking

The tool surface exposed to agents has three tiers. The first is general graph tooling: query (process-grouped hybrid search with BM25 + semantic + RRF), context (360-degree symbol view), impact (blast radius with depth grouping and confidence), trace (shortest directed path between two symbols), detect_changes (maps git diffs to affected execution flows), rename (multi-file coordinated rename over graph + text search), cypher (raw graph queries) — 15 per-repo tools in total. The second tier targets API engineering: route_map, tool_map, shape_check, and api_impact bring "which components fetch which endpoints, and do response shapes match consumer property accesses" into graph queries. The third tier is the optional --pdg index: pdg_query queries statement-level control/data dependence and explain interprets source-to-sink taint findings — close to program-dependence-graph-grade static analysis.

A typical impact call layers results into "Depth 1 will break / Depth 2 likely affected" with per-edge confidence:

impact({target: "UserService", direction: "upstream", minConfidence: 0.8})

TARGET: Class UserService (src/services/user.ts)
UPSTREAM (what depends on this):
  Depth 1 (WILL BREAK):
    handleLogin    [CALLS 90%] -> src/api/auth.ts:45
    handleRegister [CALLS 90%] -> src/api/auth.ts:78
    UserController [CALLS 85%] -> src/controllers/user.ts:12
  Depth 2 (LIKELY AFFECTED):
    authRouter     [IMPORTS]   -> src/routes/auth.ts

When several symbols share the target name, the tool refuses to guess: it returns a ranked ambiguous-candidate list, and you narrow it with target_uid, file_path, or kind. Ten MCP resources (gitnexus://repos, .../clusters, .../processes, .../schema, etc.) and two prompts (detect_impact for pre-commit change analysis, generate_map for architecture docs with mermaid diagrams) round out the discovery surface. A set of auto-installed agent skills completes the picture: /gitnexus-plan produces implementation-ready plans, /gitnexus-work executes them as impact-checked, detect_changes-gated atomic commits, /gitnexus-review does graph-backed PR review, and /gitnexus-lfg chains all three into a full pipeline.

The Indexing Pipeline: Six Phases, 14 Languages

The knowledge graph is built by a multi-phase pipeline: Structure walks the file tree and maps folder/file relationships; Parsing extracts functions, classes, methods, and interfaces via Tree-sitter ASTs; Resolution resolves imports, function calls, heritage, constructor inference, and self/this receiver types across files with language-aware logic; Clustering groups related symbols into functional communities; Processes traces execution flows from entry points through call chains; and Search builds hybrid search indexes.

Language coverage spans 14 languages: TypeScript, JavaScript, Python, Java, Kotlin, C#, Go, Rust, PHP, Ruby, Swift, C, C++, and Dart, each with its own capability matrix across import resolution, type annotations, heritage, framework pattern detection, and entry-point heuristics (the README ships a per-column comparison table). Control flow (CFG) is currently an opt-in --pdg feature, landing on TypeScript and JavaScript first with other languages planned.

Multi-repo support runs on a global registry: each analyze stores its index inside the repo's .gitnexus/ directory (gitignored, portable), and registers a pointer in ~/.gitnexus/registry.json; one MCP server can then serve every indexed repo, with lazily-opened LadybugDB connections evicted after five idle minutes. There's also analyze --watch for incremental refreshes on file changes, and gitnexus wiki generates a repository wiki from the graph (LLM-grouped module pages with cross-references, requires an LLM API key).

Engineering Base: WASM Isomorphism + Signed Supply Chain

The tech stack is deliberately isomorphic across both form factors: the CLI runs Node.js with native Tree-sitter bindings + LadybugDB (an embedded graph database with vector support, formerly KuzuDB) + transformers.js embeddings; the web runs the same pipeline in WASM, with Sigma.js + Graphology (WebGL) for visualization and a LangChain ReAct agent for chat. Search is identical on both ends: BM25 + semantic + RRF.

Supply-chain security is taken more seriously than in most open-source projects: Docker images are version-locked to the npm package (stable images are only published from vX.Y.Z git tags and must match the package.json version exactly), published identically to GHCR and Docker Hub with the same digest; everything is Cosign keyless-signed with SLSA provenance and SBOM attestations, with copy-pasteable cosign verify commands in the README; Kubernetes users can apply the bundled ClusterImagePolicy so unsigned images are rejected at admission. The MCP server also ships env-var-level controls: read-only mode, a repository allowlist, and response token budgets.

Privacy Model and Honest Limitations

Privacy is one of GitNexus's core selling points: the CLI runs entirely locally with zero network calls, indexes live in .gitnexus/, and the global registry stores only paths and metadata; the Web UI runs entirely in the browser — no code is uploaded anywhere, and API keys are stored in localStorage only. The Render one-click blueprint costs roughly $35/month and suits teams sharing indexes, though note that in that deployment the access token is the only line of defense.

Boundaries worth knowing: the license is PolyForm Noncommercial 1.0.0, so commercial use requires licensing from Akon Labs; indexing is memory-bound, so very large repos need more RAM or splitting; and the --pdg control-flow layer currently covers TS/JS only. For teams trying to make coding agents reliable, the "precompute structure into tools" thesis is worth trying directly.