Indexing a repository
Adding a code project to the same graph as your notes, and what that buys you.
As well as your notes, Nodez can read a code project and put both in the same map. This is the feature that makes Nodez different from a notes app.
Why bother#
Your vault knows what links to what note. A code project knows what imports what, what calls what, and what depends on what. Kept apart, they answer separate questions and you hold the connection between them in your head.
Put them in one graph and you can go from the note explaining a decision straight to the file that implements it - and back again. When you come back to a project after three months, that path is the thing you were missing.
Attaching a project#
In Settings → Indexing, or during the setup wizard, choose a project folder. It does not need to be related to your vault, and it does not need to be a git repository, though Nodez does more if it is.
Nodez then reads the project and adds it to the graph alongside your notes.
Nodez only reads your code. It never writes to the project folder. Nothing in the app edits your source.
What it picks up#
- Files and folders, so you can see the shape of the project
- Imports - which files pull in which
- Function calls across files
- Dependencies from
package.json - Documentation - headings inside Markdown files in the project, and links from those docs to both project files and your vault notes
That last one is the bridge: a design document in the repo can link to a note in your vault, and Nodez will connect them.
While it runs#
Indexing happens in the background and the status bar shows a spinner while it works. A large project takes a moment the first time.
After that, Nodez watches for commits rather than keystrokes. It re-indexes when the commit you are on changes - switching branch, pulling, committing - roughly every fifteen seconds. Uncommitted edits update the changed-files count in the status bar but do not restart indexing, so working normally does not send it into a loop.
Reading a big project#
Large projects would produce a graph too dense to read, so above about a thousand files Nodez draws a summary rather than everything at once: the important nodes first, with folder-containment lines hidden because they would otherwise dominate the picture.
Clicking a node expands its immediate neighbours from the full index. The status bar shows both numbers - how much is drawn, and how much is indexed - so it is clear you are looking at a view rather than the whole thing.
The full index stays complete underneath. An AI assistant querying the graph reaches all of it, not just what is on screen.
Honest limits#
One project at a time. Attaching several is planned but not built.
Call detection is approximate. Nodez reads your code structurally rather than type-checking it, so "what calls this" is a very good guide but not a guarantee. Connections found this way are marked as inferred rather than extracted, and an assistant querying the graph can tell the difference - useful for "what probably touches this", not something to bet a refactor on.
Read-only, permanently. This is not a limitation waiting to be lifted. Nodez maps your code; your editor edits it.
Last reviewed 2026-08-25