Debugging with GitNexus
When to Use
- "Why is this function failing?"
- "Trace where this error comes from"
- "Who calls this method?"
- "This endpoint returns 500"
- Investigating bugs, errors, or unexpected behavior
Bind the repository first
A root cause traced in the wrong repository is a wrong root cause.
Call list_repos {} before the first tool call. With one indexed repository,
use the examples below as written. With more than one, pass repo on every
call: an omitted repo normally errors, but under an MCP policy with a
configured default it resolves to that default silently. If you cannot tell
which repository is meant, stop and ask. This matters most for cypher, whose
statement carries no in-band hint of which database it ran against.
list_repos is paginated, so page with offset: pagination.nextOffset until
hasMore is false before concluding a repository is absent.
A stale index describes the code from before your bug, so refresh before trusting a trace, and state the repository and index freshness with the diagnosis.
Workflow
If "Index is stale" → run
node .gitnexus/run.cjs analyzein terminal. Hot-toolstalenessnames which index answered (branch/lastCommit) and how fresh it is (status). Re-analyze only forbehindordiverged—currentis identity,unknownis unmeasurable.
Checklist
Debugging Patterns
Tools
query — find code related to error:
context — full context for a suspect:
cypher — custom call chain traces. Pass repo alongside the statement; the
Cypher text itself names no repository, so the result is unattributable without
it:
trace — shortest call chain between two symbols ("how does A reach B?"), one call instead of chaining context hops:
When no path exists, trace reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).
Example: "Payment endpoint returns 500 intermittently"
With a single indexed repository, step 0 returns total: 1 and the repo
argument drops out of every call above.


