5 min read
developer-tools

GitNexus 1.4.10: Architecture, Dependencies, and Node.js Isolation Setup

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:

PackagePurpose
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:

flowchart LR A[Structure
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]
  1. Structure — Walks the file tree and maps folder/file relationships
  2. Parsing — Extracts functions, classes, methods, and interfaces using Tree-sitter ASTs
  3. Resolution — Resolves imports, function calls, heritage, constructor inference, and self/this receiver types across files
  4. Clustering — Groups related symbols into functional communities (Leiden algorithm)
  5. Processes — Traces execution flows from entry points through call chains
  6. 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:

LanguageImportsExportsHeritageType AnnotationsConstructor Inference
TypeScriptYesYesYesYesYes
JavaScriptYesYesYesYes
PythonYesYesYesYesYes
JavaYesYesYesYesYes
KotlinYesYesYesYesYes
C#YesYesYesYesYes
GoYesYesYesYesYes
RustYesYesYesYesYes
PHPYesYesYesYes
RubyYesYesYesYes
SwiftYesYesYesYes
CYesYesYes
C++YesYesYesYes
DartYesYesYesYes

MCP Tools

GitNexus exposes 7 tools through the MCP protocol:

ToolWhat It Does
list_reposDiscover all indexed repositories
queryProcess-grouped hybrid search (BM25 + semantic + RRF)
context360-degree symbol view — callers, callees, processes
impactBlast radius analysis with depth grouping and confidence
detect_changesGit-diff impact — maps changed lines to affected processes
renameMulti-file coordinated rename with graph + text search
cypherRaw 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

CategoryPackageVersionPurpose
Graph/DB@ladybugdb/core^0.15.2Embedded graph database with vector support
Graphgraphology^0.25.4Graph data structures and algorithms
Graphgraphology-indices^0.17.0Graph centrality and community indices
Graphgraphology-utils^2.3.0Graph utility functions
MCP@modelcontextprotocol/sdk^1.0.0Model Context Protocol SDK
Parsingtree-sitter^0.21.1Core AST parser
AI/ML@huggingface/transformers^3.0.0Embedding generation (optional)
AI/MLonnxruntime-node^1.24.0ONNX runtime for local inference
Serverexpress^4.19.2HTTP server for bridge mode
Servercors^2.8.5CORS middleware
CLIcommander^12.0.0CLI argument parsing
CLIcli-progress^3.12.0Progress bars
FSglob^11.0.0File pattern matching
FSignore^7.0.5Gitignore-style filtering
Datamnemonist^0.39.0Efficient data structures
Datapandemonium^2.4.0Random number generation
Cachelru-cache^11.0.0In-memory LRU cache
IDuuid^13.0.0UUID generation

Tree-sitter Language Grammars

GrammarVersionLanguage
tree-sitter-javascript^0.23.0JavaScript
tree-sitter-typescript^0.23.2TypeScript
tree-sitter-python0.23.4Python
tree-sitter-java^0.23.5Java
tree-sitter-go^0.23.0Go
tree-sitter-rust0.23.1Rust
tree-sitter-c0.23.2C
tree-sitter-cpp^0.23.4C++
tree-sitter-c-sharp^0.23.1C#
tree-sitter-ruby^0.23.1Ruby
tree-sitter-php^0.23.0PHP
tree-sitter-kotlin^0.3.8Kotlin (optional)
tree-sitter-swift^0.6.0Swift (optional)
tree-sitter-dartGitHubDart (optional)

Web UI Highlights

The web UI (gitnexus-web/) adds a separate stack:

CategoryPackagePurpose
Frontendreact@18, tailwindcss@4, vite@5Core UI framework
Graph Vizsigma, @sigma/edge-curve, graphology-layout-*WebGL graph rendering
AI/LLMlangchain, @langchain/anthropic, @langchain/openai, @langchain/google-genai, @langchain/ollamaMulti-provider AI chat
WASM@ladybugdb/wasm-core, web-tree-sitter, vite-plugin-wasmIn-browser graph + parsing
Visualizationd3, mermaid, lucide-reactCharts, 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:

PackageRequired NodeConstraint
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 VersionStatus
18.xBelow minimum — will not work
20.xSafe — minimum required
21.xBroken — glob@11 and vitest@4 reject it
22.xSafe — LTS, recommended
24.xSafe — LTS
25.xWorks 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 bash
set -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:

Terminal window
gitnexus analyze
gitnexus mcp
gitnexus status
gitnexus list

Why Node 22 over 24?

Both are LTS. I chose 22 because:

  1. Longer ecosystem maturity — native bindings (onnxruntime-node, tree-sitter) have been tested on 22 since its release
  2. Longer LTS window — security patches until April 2027
  3. 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

flowchart LR A["gitnexus analyze
(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"]
  1. The shell script loads nvm from its custom path
  2. Checks if Node 22 is installed — installs it if missing
  3. Runs npx -y gitnexus@latest under Node 22 via nvm exec
  4. Node 25 on the rest of the system is completely unaffected

Alternative Approaches

ApproachProsCons
Shell script (chosen)Transparent, works everywhere, no config changesRequires ~/.local/bin in PATH
.nvmrc fileAutomatic on cd with nvm useMust remember to nvm use every time
Global install on Node 22Direct gitnexus commandOnly available when nvm use 22 is active
Absolute path in MCP configNo script neededFragile — 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:

Terminal window
cd /path/to/your/repo
gitnexus analyze

The 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:

Terminal window
gitnexus status

This shows the index status, symbol count, relationship count, and whether the index is fresh or stale.

Key Takeaways

  1. 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.

  2. Node 22 LTS is the sweet spot — required by glob@11 and vitest@4, and the most tested version for native bindings. Node 21 is explicitly unsupported.

  3. 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.

  4. 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.