What Is GitNexus?
GitNexus is a graph-powered code intelligence tool that indexes any codebase into a knowledge graph and exposes it to AI agents through MCP (Model Context Protocol) or CLI. It tracks every dependency, call chain, cluster, and execution flow so AI assistants like Claude Code, Cursor, Codex, and OpenCode can make informed edits instead of blind guesses.
The project is by Abhigyan Patwari and lives at github.com/abhigyanpatwari/GitNexus. This article covers version 1.4.10.
Architecture Overview
GitNexus is a monorepo with two main products:
| Package | Purpose |
|---|---|
gitnexus/ | CLI + MCP server — local indexing, graph engine, query tools |
gitnexus-web/ | Browser-based graph explorer + AI chat (React + Vite) |
The ingestion pipeline works in six phases:
File tree walk] --> B[Parsing
Tree-sitter ASTs] B --> C[Resolution
Imports, calls, heritage] C --> D[Clustering
Community detection] D --> E[Processes
Execution flow tracing] E --> F[Search
BM25 + semantic + RRF]
- Structure — Walks the file tree and maps folder/file relationships
- Parsing — Extracts functions, classes, methods, and interfaces using Tree-sitter ASTs
- Resolution — Resolves imports, function calls, heritage, constructor inference, and
self/thisreceiver types across files - Clustering — Groups related symbols into functional communities (Leiden algorithm)
- Processes — Traces execution flows from entry points through call chains
- Search — Builds hybrid search indexes (BM25 + semantic vectors + Reciprocal Rank Fusion)
The graph is stored in LadybugDB (formerly KuzuDB) under .gitnexus/ in the repo root, with a global registry at ~/.gitnexus/registry.json for multi-repo support.
Language Support
GitNexus supports 14 languages with varying levels of analysis:
| Language | Imports | Exports | Heritage | Type Annotations | Constructor Inference |
|---|---|---|---|---|---|
| TypeScript | Yes | Yes | Yes | Yes | Yes |
| JavaScript | Yes | Yes | Yes | — | Yes |
| Python | Yes | Yes | Yes | Yes | Yes |
| Java | Yes | Yes | Yes | Yes | Yes |
| Kotlin | Yes | Yes | Yes | Yes | Yes |
| C# | Yes | Yes | Yes | Yes | Yes |
| Go | Yes | Yes | Yes | Yes | Yes |
| Rust | Yes | Yes | Yes | Yes | Yes |
| PHP | Yes | Yes | — | Yes | Yes |
| Ruby | Yes | Yes | Yes | — | Yes |
| Swift | — | Yes | Yes | Yes | Yes |
| C | — | Yes | — | Yes | Yes |
| C++ | — | Yes | Yes | Yes | Yes |
| Dart | Yes | — | Yes | Yes | Yes |
MCP Tools
GitNexus exposes 7 tools through the MCP protocol:
| Tool | What It Does |
|---|---|
list_repos | Discover all indexed repositories |
query | Process-grouped hybrid search (BM25 + semantic + RRF) |
context | 360-degree symbol view — callers, callees, processes |
impact | Blast radius analysis with depth grouping and confidence |
detect_changes | Git-diff impact — maps changed lines to affected processes |
rename | Multi-file coordinated rename with graph + text search |
cypher | Raw Cypher graph queries |
Dependency Analysis
I analyzed the full dependency tree of v1.4.10. Here’s what the CLI package depends on:
Core Dependencies
| Category | Package | Version | Purpose |
|---|---|---|---|
| Graph/DB | @ladybugdb/core | ^0.15.2 | Embedded graph database with vector support |
| Graph | graphology | ^0.25.4 | Graph data structures and algorithms |
| Graph | graphology-indices | ^0.17.0 | Graph centrality and community indices |
| Graph | graphology-utils | ^2.3.0 | Graph utility functions |
| MCP | @modelcontextprotocol/sdk | ^1.0.0 | Model Context Protocol SDK |
| Parsing | tree-sitter | ^0.21.1 | Core AST parser |
| AI/ML | @huggingface/transformers | ^3.0.0 | Embedding generation (optional) |
| AI/ML | onnxruntime-node | ^1.24.0 | ONNX runtime for local inference |
| Server | express | ^4.19.2 | HTTP server for bridge mode |
| Server | cors | ^2.8.5 | CORS middleware |
| CLI | commander | ^12.0.0 | CLI argument parsing |
| CLI | cli-progress | ^3.12.0 | Progress bars |
| FS | glob | ^11.0.0 | File pattern matching |
| FS | ignore | ^7.0.5 | Gitignore-style filtering |
| Data | mnemonist | ^0.39.0 | Efficient data structures |
| Data | pandemonium | ^2.4.0 | Random number generation |
| Cache | lru-cache | ^11.0.0 | In-memory LRU cache |
| ID | uuid | ^13.0.0 | UUID generation |
Tree-sitter Language Grammars
| Grammar | Version | Language |
|---|---|---|
tree-sitter-javascript | ^0.23.0 | JavaScript |
tree-sitter-typescript | ^0.23.2 | TypeScript |
tree-sitter-python | 0.23.4 | Python |
tree-sitter-java | ^0.23.5 | Java |
tree-sitter-go | ^0.23.0 | Go |
tree-sitter-rust | 0.23.1 | Rust |
tree-sitter-c | 0.23.2 | C |
tree-sitter-cpp | ^0.23.4 | C++ |
tree-sitter-c-sharp | ^0.23.1 | C# |
tree-sitter-ruby | ^0.23.1 | Ruby |
tree-sitter-php | ^0.23.0 | PHP |
tree-sitter-kotlin | ^0.3.8 | Kotlin (optional) |
tree-sitter-swift | ^0.6.0 | Swift (optional) |
tree-sitter-dart | GitHub | Dart (optional) |
Web UI Highlights
The web UI (gitnexus-web/) adds a separate stack:
| Category | Package | Purpose |
|---|---|---|
| Frontend | react@18, tailwindcss@4, vite@5 | Core UI framework |
| Graph Viz | sigma, @sigma/edge-curve, graphology-layout-* | WebGL graph rendering |
| AI/LLM | langchain, @langchain/anthropic, @langchain/openai, @langchain/google-genai, @langchain/ollama | Multi-provider AI chat |
| WASM | @ladybugdb/wasm-core, web-tree-sitter, vite-plugin-wasm | In-browser graph + parsing |
| Visualization | d3, mermaid, lucide-react | Charts, diagrams, icons |
Node.js Version Requirements
This is where it gets interesting. The declared minimum is >=20.0.0, but the actual constraints are tighter when you look at the dependency tree:
Minimum: Node.js 20.x
The hard floor comes from two dependencies:
| Package | Required Node | Constraint |
|---|---|---|
glob@11 | "20 || >=22" | Node 21 is unsupported |
vitest@4 | "^20.0.0 || ^22.0.0 || >=24.0.0" | Explicit version pinning |
All other dependencies accept Node 18 or even older, but these two lock you to 20, 22, or 24+.
Maximum: No Hard Ceiling
No dependency in the tree declares an upper Node.js bound. The @types/node@^24.10.1 in the web UI suggests the project has been tested through Node 24+.
Safe Range
| Node Version | Status |
|---|---|
| 18.x | Below minimum — will not work |
| 20.x | Safe — minimum required |
| 21.x | Broken — glob@11 and vitest@4 reject it |
| 22.x | Safe — LTS, recommended |
| 24.x | Safe — LTS |
| 25.x | Works but risky — Current (non-LTS), native bindings may lack prebuilt binaries |
The Problem: Isolating GitNexus on a Node 25 System
My system runs Node 25. GitNexus requires Node 20–24. The native dependencies (onnxruntime-node, tree-sitter) use prebuilt C++ binaries that are most battle-tested on LTS versions.
Running npm install -g gitnexus on Node 25 works in theory but risks native module compatibility issues. And switching my entire system to Node 22 just for one tool isn’t practical — all my other tools (OpenCode, context-mode, etc.) are configured for Node 25.
The solution: isolate GitNexus under a specific Node version using nvm, wrapped in a shell script so it’s transparent.
The Setup: nvm Isolation
My nvm lives at a non-standard path (~/.config/nvm instead of ~/.nvm). The shell script handles this:
#!/usr/bin/env bashset -euo pipefail
export NVM_DIR="${NVM_DIR:-$HOME/.config/nvm}"[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
NODE_VERSION="22"
if ! nvm ls "$NODE_VERSION" | grep -q "$NODE_VERSION"; then echo "Node $NODE_VERSION not found. Installing..." >&2 nvm install "$NODE_VERSION"fi
nvm exec "$NODE_VERSION" npx -y gitnexus@latest "$@"Save this to ~/.local/bin/gitnexus, make it executable (chmod +x), and it works like a native command:
gitnexus analyzegitnexus mcpgitnexus statusgitnexus listWhy Node 22 over 24?
Both are LTS. I chose 22 because:
- Longer ecosystem maturity — native bindings (
onnxruntime-node,tree-sitter) have been tested on 22 since its release - Longer LTS window — security patches until April 2027
- Lower risk with C++ addons — fewer edge cases with native compilation
Node 24 works too, but since GitNexus relies heavily on native binaries, 22 minimizes the blast radius if something goes wrong during installation.
How It Works
(shell script)"] --> B["nvm exec 22"] B --> C["npx gitnexus@latest"] C --> D["Node 22 runtime"] D --> E["LadybugDB + Tree-sitter"] E --> F[".gitnexus/ index"]
- The shell script loads nvm from its custom path
- Checks if Node 22 is installed — installs it if missing
- Runs
npx -y gitnexus@latestunder Node 22 vianvm exec - Node 25 on the rest of the system is completely unaffected
Alternative Approaches
| Approach | Pros | Cons |
|---|---|---|
| Shell script (chosen) | Transparent, works everywhere, no config changes | Requires ~/.local/bin in PATH |
.nvmrc file | Automatic on cd with nvm use | Must remember to nvm use every time |
| Global install on Node 22 | Direct gitnexus command | Only available when nvm use 22 is active |
| Absolute path in MCP config | No script needed | Fragile — breaks if Node version changes |
Configuring MCP with the Script
For editor integration (OpenCode, Claude Code, Cursor), point the MCP config to the shell script:
{ "mcp": { "gitnexus": { "type": "local", "command": "/home/youruser/.local/bin/gitnexus", "args": ["mcp"] } }}The script handles the Node version automatically. The editor doesn’t need to know about nvm or Node 22.
First Run
After setting up the script, index your project:
cd /path/to/your/repogitnexus analyzeThe first run takes longer because it downloads Node 22 (if not installed) and the GitNexus npm package. Subsequent runs are fast — npx caches the package and nvm exec is nearly instant.
To verify:
gitnexus statusThis shows the index status, symbol count, relationship count, and whether the index is fresh or stale.
Key Takeaways
-
GitNexus is not just a search tool — it builds a full knowledge graph with precomputed clustering, execution flows, and confidence scores. The AI agent gets complete context in one tool call, not a chain of 10 grep operations.
-
Node 22 LTS is the sweet spot — required by
glob@11andvitest@4, and the most tested version for native bindings. Node 21 is explicitly unsupported. -
nvm isolation is clean — a 14-line shell script lets you run GitNexus on Node 22 while keeping Node 25 for everything else. No container, no virtual environment, no system-wide changes.
-
The MCP wrapper makes it transparent — your editor sees one command that handles version management internally. No special configuration or manual switching.
This article was written by opencode (GLM-5), based on analysis of GitNexus v1.4.10 source code and dependency tree.

