Key takeaways
- GitNexus supplies graph context to coding agents through 17 documented MCP tools.
- Incremental indexing and watch mode have shipped; the earlier roadmap-only warning is obsolete.
- Local indexing does not make remote embeddings, model calls, or hosted deployments private by default.
- PolyForm Noncommercial restricts usage; Akon Labs offers separate commercial licensing.
FAQ
What is GitNexus?
A repository graph engine that exposes structural code context to AI coding agents through MCP, a CLI, and a browser interface.
Is GitNexus open source?
It is source-available under PolyForm Noncommercial 1.0.0, which restricts permitted purposes. Akon Labs offers commercial licensing separately.
Does code stay on my machine?
Local indexing is available, but remote embedding services, configured model providers, connected agents, and hosted deployments change where data goes. Review the chosen configuration.
Is incremental indexing available?
Yes. The stable v1.6.12 documentation includes incremental analyze and a watch mode for local file changes.
Executive Summary
GitNexus builds repository graphs and supplies their structural context to coding agents through MCP. It combines a local CLI with a browser explorer and editor integrations. It belongs in the code intelligence tools category, as an additional source of evidence for an agent's edits.[1]
The September 15, 2026 review changes two earlier conclusions: incremental indexing is available, and local operation is a deployment option rather than a universal privacy guarantee. Akon Labs also markets hosted and self-hosted enterprise deployments.[1][2]
| Attribute | Verified position |
|---|---|
| Stable release | v1.6.12, September 12, 2026[3] |
| License | PolyForm Noncommercial 1.0.0; source-available with purpose restrictions[4] |
| Enterprise offering | Akon Labs; sales-led, with no public list price found on its site in this review[2] |
Product Overview
The TypeScript project on GitHub documents 17 MCP tools: 15 repository tools and two group tools. These cover search, symbol context, impact, tracing, change detection, renaming, API structure, and optional program-dependence queries. Claude Code, Cursor, Antigravity, and Codex have documented MCP, skills, and hooks integration; OpenCode, CodeBuddy, Qoder, and Windsurf have narrower integrations.[1]
Index a repository with gitnexus analyze, configure an editor with gitnexus setup, and use analyze --watch for file-driven incremental refreshes. An index still needs freshness checks; automatic triggers do not establish correctness.[1][5]
CLI, browser, and bridge modes
The CLI maintains a persistent native LadybugDB index for recurring agent work. The standalone browser explorer uses WebAssembly parsing and storage for interactive exploration; available browser memory limits its practical scale. gitnexus serve can connect the browser UI to a CLI-built index, avoiding a separate browser reindex. These are different operating modes, not different guarantees of graph completeness. [1]
Choosing the right query
The current tool contracts support a staged investigation rather than requiring an agent to retrieve the whole repository: [6]
| Question | Tool |
|---|---|
| Which indexed repository should I query? | list_repos |
| Which flows relate to this concept? | query |
| What calls this symbol, and what does it call? | context |
| What depends on the symbol I plan to change? | impact |
| How does one named symbol reach another? | trace |
| What graph relationships are affected by my diff? | detect_changes |
| What would this rename modify? | rename, which previews by default |
| Where is a route handled or consumed? | route_map and api_impact |
These tools have different assumptions. For example, renaming combines graph references with lower-confidence text matches, and optional statement-level dependence queries need a --pdg index. Review the preview and evidence rather than treating a tool name as a correctness guarantee. [6]
Example: investigate and change a shared function
Start by checking index status, refreshing when it is behind the working revision, and finding the relevant flow. Inspect the target symbol and its incoming dependencies before editing. Use the rename preview if the task changes a public name; after the edit, inspect the diff's affected relationships and run the repository's real checks. This sequence is an evaluation workflow, not a reproduced benchmark.
The operational detail that matters is freshness plus completeness. The runbook distinguishes an out-of-date index from failed or unverified scope extraction. For those incomplete cases, impact results are a lower bound; an empty caller list is not proof that no caller exists. It recommends reanalysis and inspection of remaining extraction warnings. [5]
Similarly, a successful analysis can leave an embedding checkpoint pending. Semantic retrieval and structural retrieval need separate verification; existing vector counts alone are not proof that all changed symbols received embeddings. That matters when comparing a keyword result with a semantic query or diagnosing an apparently missing feature. [5]
Technical Architecture
Local indexing uses Tree-sitter and embedded LadybugDB. LadybugDB is a separately maintained successor to KuzuDB, not a custom database created solely for GitNexus.[1][7]
The documented pipeline moves from file and symbol extraction to import/call resolution, community clustering, execution-flow construction, and search indexing. Those layers answer different questions: a text match locates a candidate, a relationship connects symbols, and a derived flow organizes a possible execution path. [1]
The v1.6.12 release adds configurable external index locations and three source-retention modes: full text, symbol snippets, or structural data without source bodies. It also adds Objective-C support and resumable embedding jobs. Staleness reporting distinguishes current, behind, diverged, and unknown states rather than treating unresolved revision checks as fresh.[3]
These are useful operational controls, not proof that the graph includes every runtime dependency. The same release corrects language-resolution errors and excludes guessed call edges from derived flows, showing why a graph should complement source review and tests.[3]
Strengths
- Queryable structure: agents can inspect relationships before changing code, with a common interface across repositories.[1]
- Portable indexes: storage and retention controls suit managed workspaces where indexes must outlive a checkout.[3]
- Documented recovery: the runbook covers stale indexes, embedding failures, memory pressure, and MCP troubleshooting.[5]
Cautions
- Deployment controls matter: the security policy says a hosted Render access token grants access to all indexed repositories. A directly reachable server needs authentication or an appropriate private boundary.[8]
- Local is configuration-dependent: embedding endpoints and LLM-backed wiki generation can send data to configured providers. An attached coding agent has its own data handling.[1]
- Capacity requires measurement: the runbook documents heap exhaustion and tuning. No universal repository-size guarantee was established in this review.[5]
- Commercial terms differ: the public license permits specified noncommercial purposes; it is not a permissive commercial-use license.[4]
What Developers Say
A useful first-hand report is GitHub user kam-ship-it's July 9, 2026 issue about failed incremental commits on v1.6.8, using Windows and a repository of roughly 4,670 files. The issue is closed and linked to a fix. It documents a historical failure, not evidence that the current release has the same defect.[9]
This review did not independently benchmark the current release. Earlier headline claims about token savings and production performance are omitted because they were not established here through reproducible primary evidence.
Pricing & Licensing
| Offering | Terms checked September 15, 2026 |
|---|---|
| Public code | PolyForm Noncommercial; permitted-purpose restrictions apply[4] |
| Commercial and enterprise | Contact Akon Labs for commercial licensing or managed/self-hosted deployment[2] |
Hosting and configured model or embedding services can introduce additional costs. The runbook supports both local and remote embedding configurations; free access to code does not imply a free deployment.[5]
Bottom Line
Recommended for: teams willing to evaluate graph accuracy and index freshness on their own repositories, with licensing and deployment choices resolved first.
Poor fit: buyers requiring unrestricted commercial use under the public license or assuming that a local-capable tool guarantees code never leaves the machine.
Outlook: the current release provides concrete operational improvements. The meaningful evaluation is whether its graph answers help the team's actual work, and whether maintenance costs justify that benefit—not repository popularity alone.
Research by Ry Walker • methodology
Sources
- [1] GitNexus v1.6.12 README
- [2] Akon Labs — GitNexus enterprise offering
- [3] GitNexus v1.6.12 release — September 12, 2026
- [4] GitNexus PolyForm Noncommercial license
- [5] GitNexus v1.6.12 operational runbook
- [6] GitNexus v1.6.12 MCP tool contracts
- [7] LadybugDB — embedded graph database and KuzuDB successor
- [8] GitNexus security policy and hosted deployment boundaries
- [9] GitNexus issue #2409 — incremental commit failure on v1.6.8