GitNexus: The Zero-Server Code Intelligence Engine

TL;DR

GitNexus is a local-first code-intelligence engine (Node.js CLI + MCP server + web graph explorer) that indexes a codebase into a tree-sitter-backed knowledge graph of symbols, calls, dependencies, and execution flows, then exposes it to coding agents (Claude Code, Cursor, Codex, Factory Droid, OpenCode, CodeBuddy, Qoder, Antigravity) as a fixed MCP tool surface — query, context, impact, trace, detect_changes, rename. The indexer runs locally without an LLM against a LadybugDB (formerly KuzuDB) embedded graph+vector store; only optional remote embeddings / wiki generation / AI chat touch external providers. Positioned as “deeper than” shallow code-map tools: the primary deliverable is a persistent structured artifact about the repo that any attached agent can traverse rather than an inline retrieval service.

Key claims

Zero-LLM local indexing: the CLI builds the graph using tree-sitter parsers against 18 languages (C, C++, C#, COBOL, Dart, Go, Java, JavaScript, Kotlin, Objective-C, PHP, Python, Ruby, Rust, Swift, TypeScript, Vue, Zig — with per-language coverage inventories in docs/languages/), with no LLM involved in index construction [README §Supported languages, §Security and privacy].
Fixed six-tool MCP surface designed around code-understanding verbs rather than free-form search: query (find code + related execution flows), context (inspect callers + dependencies), impact (what a change could affect), trace (path between two symbols), detect_changes (review impact of a Git diff), rename (preview + apply a semantic rename) [README §What you can do].
Multi-client topology is first-class: a single gitnexus mcp --http --port 3111 server can be shared across concurrent agents at http://127.0.0.1:3111/mcp, rather than the one-stdio-per-agent default most MCP servers ship with [README §Everyday commands].
Repository-integration side effects are the default install path: npx gitnexus analyze not only builds the index but also installs agent skills, registers Claude Code hooks, and writes AGENTS.md / CLAUDE.md context files; a separate --index-only flag is required to opt out [README §Quick start].
Watch-mode reindexing (gitnexus analyze --watch) is advertised for keeping the graph in sync with local edits as the agent works, with a gitnexus status command for index-freshness checks [README §Everyday commands].
Enterprise variant adds PR Review (automated blast-radius analysis on pull requests), auto-updating code wiki, auto-reindexing, multi-repo unified graph, and OCaml — the OSS release notably excludes multi-repo unified graphs and PR-review integration [README §Enterprise].

Method

GitNexus is structured as three co-located surfaces over one index: (a) a CLI that drives indexing, status, impact/query/rename commands directly from the terminal; (b) an MCP server (stdio by default, --http for shared mode) that exposes the six tools to coding agents; (c) a static web UI at gitnexus.vercel.app that connects to the local backend via gitnexus serve and offers a Sigma.js WebGL graph explorer plus AI chat. The index itself lives in a LadybugDB embedded graph database with vector support — a combined graph+vector store that lets the “query” tool blend structural traversal (callers, call graph, dependency edges) with semantic retrieval (embeddings) in a single query. Tree-sitter AST parsing produces the symbol/call/dependency nodes; the type-resolution layer (documented in type-resolution-system.md + roadmap) adds language-level resolution on top for the construct categories where tree-sitter alone is insufficient. Index-freshness is tracked explicitly, with gitnexus status and gitnexus list as first-class commands.

The AGENTS.md / CLAUDE.md files written at install time are the mechanism by which GitNexus hands its tool surface to any attached coding agent — a context-file onboarding contract parallel to the DimOS pattern (see DimOS — The Agentive Operating System for Physical Space (v0.0.13)) but for code-understanding rather than embodied skills.

Results

No benchmarks are reported in the README. The project cites a TrendShift badge and lists OpenSSF Scorecard + CI workflow badges as its public quality signals. Resolution behavior is explicitly best-effort: the README calls out that “resolution depends on language support and available evidence” and tells agents to “check reported ambiguity, index freshness and coverage limits” — i.e., GitNexus does not claim total recall, and surfaces its own uncertainty to the agent.

Deployment artifacts: npm package gitnexus, a public web UI, Docker + Render deployment paths, and three community integrations (pi-gitnexus plugin for pi.dev, gitnexus-stable-ops deployment workflows, a KiloCode MCP workflow guide).

Why it’s interesting

GitNexus sits in the same slot as the AGENTS.md-contract pattern that DimOS — The Agentive Operating System for Physical Space (v0.0.13) uses for embodied agents and that metal-arm-harness (see metal-arm-harness — Arm-agnostic coding-agent harness for MakerMods Metal (Isaac Sin)) uses for robot arms — a persistent artifact that any attached coding agent can read to bootstrap itself over a well-typed tool surface — but for code understanding rather than hardware control. That makes it a direct example of the harness-level-code-navigation axis that Agentic Software Engineering has been tracking: Qwen3-Coder-Next (Qwen3-Coder-Next Technical Report §3.1.1) argues long-context + repo-level pretraining is a prerequisite for cross-file agentic work, but GitNexus takes the opposite bet — keep the model context cheap and push structural knowledge into an external graph the agent queries on demand. Patrick’s framing in the Slack message (“a bit deeper than what trail does here”) suggests the thread was comparing shallow code-map tools (which the attached agent must re-infer from path listings) against persistent-graph tools where the semantic topology survives across sessions. The planned combination of “trail learnings” with the GitNexus map is the natural next step on that axis.