Table of Contents

Why I Decided to Try GitNexus

I recently came across GitNexus while looking for tools that might work well with Claude Code.

GitNexus analyzes a repository and builds a graph of relationships between files, functions, call paths, and execution flows. It can also integrate with Claude Code, Cursor, and other tools through MCP. That sounded useful for helping an AI understand an existing project, so I decided to try it on a system I'm still developing.

My first impression is that GitNexus did not suddenly make Claude Code dramatically smarter. The automatic Wiki generation, however, was surprisingly good. For understanding the overall structure of an existing system or creating handover documentation, it looks genuinely useful.

I tested GitNexus with Claude Code, generated a project Wiki, and even asked Claude Code to look for bugs using the GitNexus analysis.

What Is GitNexus?

GitNexus analyzes repositories and builds a knowledge graph showing how pieces of code relate to one another.

Claude Code can already search files, trace function calls, and inspect dependencies on its own. GitNexus analyzes those relationships ahead of time and makes them available through MCP. That means Claude Code can query things such as:

  • What could be affected if this function changes?
  • Where is this code called from?
  • Which files are involved in this feature?

I think of it less as giving Claude Code a completely new capability and more as giving it a pre-built map of the project.

The CLI Version Makes Sense If You Use Claude Code

GitNexus also has a web version, but I wanted to use it together with Claude Code, so I tried the CLI. From the project root, you can run:

npx gitnexus analyze

GitNexus then analyzes the repository. For the project I tested, the result was:

  • 852 nodes
  • 2,244 edges
  • 29 clusters
  • 67 flows

The analysis took about 172 seconds. At that point, files, functions, call relationships, and other structural information had been added to the GitNexus graph.

The analysis results are mainly stored inside the project under .gitnexus/. So if I close Claude Code and reopen the same project the next day, GitNexus can reuse the existing analysis. That is certainly convenient. Claude Code does not have to rediscover the entire structure from scratch every time.

There Are Limits to the Analysis

One thing caught my attention during the first analysis. GitNexus printed messages like:

truncation: entryPointsUnexplored=77, calleesDropped=120, processesDropped=48

It also reported 67 flows reported, but whole flows are MISSING.

Important: At first, I wondered whether this was some kind of free-plan limitation. After looking into it, that does not appear to be the case. These limits exist to keep the amount of analysis under control. GitNexus limits things such as how deeply execution flows are traced and how many branches are followed. On a larger project, it may therefore skip some execution flows. That does not mean only part of the 852-node graph was indexed — the main code graph still exists. What was truncated was part of the higher-level flow analysis built on top of it.

There is also a --embeddings 0 option that removes the default 50,000-node limit for embeddings, but that is separate from the execution-flow limits. This part of GitNexus was a little confusing at first.

Does GitNexus Actually Make Claude Code Smarter?

This was the main thing I wanted to know. I had already been using Claude Code for a lot of programming work, including bug fixes and debugging, before trying GitNexus. So I wanted to see whether adding GitNexus would lead to noticeable improvements such as:

  • finding bugs that Claude Code normally misses
  • making fewer mistakes during complicated changes

With GitNexus installed, Claude Code can run an impact analysis before editing code. For example, instead of relying only on grep or text search, it can use the GitNexus graph to investigate what might break if a particular function changes. That is useful.

But if you already use Claude Code regularly, you know that Claude itself is quite capable of searching through files and tracing code carefully. In practice, I did not get the feeling that Claude Code became a completely different tool after installing GitNexus. It felt more like Claude Code had gained an additional source of information when investigating an existing codebase.

I Asked GitNexus and Claude Code to Look for Bugs

Since GitNexus already had a graph of the project, I decided to see whether it could help uncover actual problems. The system I tested is still under development. There are still areas where, if a person actually uses the application, they might think, "This behavior feels a little strange."

I first ran GitNexus's structural checks and then added PDG analysis. PDG is used to track how data moves through a program. I then asked Claude Code to use GitNexus taint analysis to look for potentially dangerous data flows involving things such as:

  • code injection
  • path traversal
  • SQL injection
  • XSS

The result was zero findings. Of course, zero findings does not prove that the application is completely safe. GitNexus itself has limitations — some flows involving closures, callbacks, DOM operations, and similar patterns cannot be tracked perfectly. So Claude Code followed up by checking the actual source code.

Example: It reviewed places using innerHTML, SQL-related code, and other potentially risky areas. Eventually, it found one implementation that was worth noting: on the server side, a user-supplied IP address was being included directly in an error message returned as JSON. However, the client displayed that message using textContent rather than innerHTML, so the current implementation does not create an XSS vulnerability. In other words, it was basically harmless right now, but potentially risky if the display code changes in the future.

Based on this test, GitNexus did not uncover some major bug that Claude Code had previously missed. The more accurate description is that Claude Code used the GitNexus analysis as a starting point, performed additional investigation, and found one very minor potential issue.

It Obviously Cannot Find "Bugs" That Only Feel Wrong to a Human User

The system I tested still has a few areas that feel odd when I actually use it. The software may technically be working as designed, but the experience can still be questionable. For example:

  • "This screen transition feels strange."
  • "This action is awkward for the user."
  • "The implementation is technically correct, but it does not work very well in the actual business workflow."

GitNexus cannot really detect this kind of problem. Its analysis is based on code structure, call relationships, and data flow. It cannot understand how a person feels while using the system. For these kinds of issues, human testing or end-to-end testing with something like Playwright is much more appropriate.

The Wiki Generation Was Probably My Favorite Feature

The feature I liked most was the automatic Wiki generation. GitNexus can generate a Wiki for the entire system from the analyzed project.

When I looked at the result, it was much more than a simple list of files. It described the purpose of the system, major features, the role of each module, and the flow of processing in plain language. In the project I tested, it even understood the context of Japan's Ministry of Health, Labour and Welfare stress-check system and explained the functionality using the appropriate domain terminology.

That is useful if you return to a project after several months and need to understand it again. It also looks good enough to use when handing a system over to another developer — you could realistically say "start by reading this Wiki." Personally, I found this part of GitNexus easier to appreciate than the MCP integration with Claude Code.

How Does GitNexus Generate the Wiki?

The Wiki generation uses an LLM. In my case, the execution log showed:

Spawning: cmd.exe /c claude -p --output-format text --no-session-persistence
Model: default

So GitNexus was not directly calling the Anthropic API with a separate API key. Instead, it was invoking the Claude Code CLI already installed on my PC. During this Wiki generation, claude -p was called roughly 16 times.

Important: It would be misleading to say "GitNexus Wiki generation is completely free." There was no separate Anthropic API charge, but it still consumed my Claude Code usage allowance. A more accurate description is that I was able to generate the Wiki using my existing Claude Code plan without preparing an additional API key or paying separate API fees. For people who already use Claude Code regularly, that is a nice benefit.

The Biggest Concern: The Analysis Can Become Stale

This is the part that made me a little nervous. GitNexus stores its analysis of the current code structure under .gitnexus. Naturally, once the source code changes, the GitNexus graph and the actual code can start to drift apart.

Warning: Imagine that GitNexus says "this function is called from three places," but since the last analysis, you have added a fourth caller. If Claude Code trusts the old graph during an impact analysis, it could make the wrong decision. That is an uncomfortable possibility because impact analysis is one of the main reasons to use GitNexus in the first place. If the graph is stale, the tool meant to reduce bugs could potentially contribute to one instead.

GitNexus has mechanisms that can detect when the index may be outdated and remind you to re-analyze the project, but in practice you still need to run npx gitnexus analyze again yourself. For my project, the analysis took around three minutes. If you are in the early stages of development and changing files, architecture, and behavior every day, repeatedly re-running the analysis could become annoying.

Uninstalling GitNexus Does Not Automatically Remove Its CLAUDE.md Instructions

Another thing I noticed is that GitNexus modifies CLAUDE.md and AGENTS.md. When you run npx gitnexus analyze, GitNexus adds a managed section between markers such as <!-- gitnexus:start --> and <!-- gitnexus:end -->. Inside that section, it adds instructions telling Claude Code to use GitNexus, for example by running impact analysis before edits and detect_changes before commits.

The slightly awkward part is what happens when you decide to stop using GitNexus. You might assume that one of the following would completely clean things up:

  • delete the .gitnexus folder
  • gitnexus clean
  • gitnexus uninstall

Warning: But those actions do not automatically remove the GitNexus section from CLAUDE.md or AGENTS.md. That means you can remove the GitNexus index and MCP integration while leaving behind instructions telling Claude Code to use GitNexus. Because Claude Code reads the project's CLAUDE.md, it may still behave as though GitNexus tools are available even after GitNexus itself has been removed.

To fully revert the project, you need to manually delete the block between <!-- gitnexus:start --> and <!-- gitnexus:end -->. Using analyze --skip-agents-md can stop GitNexus from updating its managed sections in CLAUDE.md and AGENTS.md going forward, but it does not remove content that has already been written. So even if you install GitNexus just to "try it for a while," it is worth remembering that uninstalling it may require some manual cleanup inside the repository.

GitNexus May Be Better Suited to Projects That Are Already Fairly Stable

After trying it, I get the feeling GitNexus may be more useful on a project that is already reasonably mature than on one that is changing rapidly from day one. Early in development, everything changes: files are added, functions are rewritten, architecture changes, and screens are reorganized. The GitNexus analysis can become outdated very quickly, and then you have to analyze the project again.

On a system that is mostly complete and only receives occasional changes, the situation is different. You can analyze it once and keep using the result for much longer. The generated Wiki is also valuable when you return to the project months later. Another reasonable workflow would be to re-run GitNexus only before larger changes, then use Claude Code to inspect the impact. For that kind of project, the benefits start to look more convincing.

Before trying GitNexus, I was hoping it might help Claude Code find significantly more bugs. So far, I have not seen that kind of dramatic improvement. Claude Code is already quite good at reading a codebase without GitNexus. If you already rely on Claude Code for debugging and implementation work, installing GitNexus probably will not suddenly improve your code quality by several levels.

Where GitNexus does seem useful is in analyzing the structure of a project, understanding relationships between functions and files, checking the impact of changes, and generating a Wiki from an existing system. The Wiki in particular provides a very visible benefit because it turns source code into documentation that developers can actually read. GitNexus feels more like a map of your codebase than a bug-finding tool, and that is probably the right expectation to have going in.

I'll Keep Using It for a While, but I'm Not Sure Yet Whether It Will Become Part of My Standard Workflow

Before testing GitNexus, I thought it might significantly improve Claude Code's ability to understand a codebase. After using it, I think the reality is more nuanced.

It definitely gives Claude Code useful additional information, but Claude Code is already quite capable without it. At the same time, GitNexus adds another maintenance task: keeping its analysis up to date. If you forget to re-analyze the repository, Claude Code may end up looking at an outdated map of the project, which could potentially work against you.

At this point, I do not feel like installing GitNexus in every project I am actively developing. For projects that are mostly complete, or large existing systems that I need to understand or take over, I can see it being much more useful. The Wiki generation in particular is a feature I genuinely liked.

I plan to keep using GitNexus in real development for a while and see whether having it available actually reduces investigation time or improves the accuracy of Claude Code's changes over the longer term. I've been testing a few other tools with a similarly quiet-but-useful profile too, like Wrangler auth profiles. As with choosing the right AI tool for a given task, I'd rather try things myself before deciding whether they earn a permanent place in the workflow.