Guides · updated July 2026
How to index a codebase for AI: the right way.
Most guides answer this the same way: point your editor at a repo, wait for it to build an index, and rebuild it whenever things drift. It works: for the one folder you opened, in the one tool you opened it in, until the next save makes it stale. Do that per repo, per tool, on a schedule, forever. There is a simpler answer, and a real 4.47-million-file machine proves it out: index the whole machine once, keep it fresh automatically, and hand the same map to every agent. Here are your options, honestly ranked, and the setup.
The short version
Index once, machine-wide. Not once per repo, forever.
Indexing a codebase for AI means building a searchable map of your files (their names and their contents) that an agent can query in a single tool call instead of grepping the disk from scratch every time it needs something. The question this guide settles is where you draw the box: around one repo, or around the whole machine.
Four ways to make a codebase searchable
Your options, honestly ranked.
There are four real ways to give an AI agent search over your code. Each is good at the job it was built for: the differences are what they cover, how they stay fresh, and which agents can actually use them.
| The approach | What it covers | Fresh after a save | Which agents can use it |
|---|---|---|---|
| grep / ripgrep, on demand | Nothing kept: walks the disk each query | Always current, never pre-built | Any agent, but it re-scans every time |
| Per-repo embeddings (Cursor) | The one repo you opened, as meaning | Re-embeds edits, cloud round-trip | Only Cursor |
| Org code graph (Sourcegraph) | Many repos, the pushed state | Re-index cycles, on a server | Its own UI and API |
| Whole-machine live index (Interlinked) | Every file: names + contents, all repos + non-git | ~1 ms after you save | Every agent, one connector |
The top three are the standard playbook, and every one of them draws its box around a subset of your work. grep and ripgrep keep nothing, so they pay the full scan on every query. Cursor's embeddings are excellent, but they stop at the folder you opened and live in Cursor's vault, reachable only from Cursor. Sourcegraph sees many repos, but on a server, and only the state you pushed. The fourth row is the one nobody set as the default.
The choice, drawn to scale
Many small islands, or one whole map.
Put the two approaches side by side and the trade-off stops being abstract. On the left, an index per repo, per tool, rebuilt on its own timer, each one an island that cannot see the next. On the right, a single index over the whole machine, fresh a millisecond after you save, handed to every agent at once.
Every repo needs its own index job, and every save leaves it a little stale between runs. Multiply by the number of tools you use, and you are maintaining a fleet of indexes that never quite agree with each other.
It covers every repo and the non-git files in the same map, and it updates itself the instant a file changes, so an agent never acts on a stale answer without knowing it.
Because one connector exposes it, Claude Code, Cursor and Copilot all read the identical index. Nothing has to be re-indexed per agent, and no vendor holds it hostage.
Freshness is architecture, not a schedule
A re-index cycle is a promise to be wrong for a while.
Any index rebuilt on a timer is correct right after it runs and drifting every second after. In the gap, the agent searches confidently and gets yesterday's answer, the worst kind of wrong, because it looks right. The fix is not a shorter timer. It is to stop using a timer at all: the moment you save a file, the system hands the change straight to the index, and the edit is searchable about a millisecond later, searchable before your finger leaves the key, under 30 ms even in the worst case.
Whole-machine matters for the same practical reason. An agent's questions do not respect folder boundaries: the answer is often in a sibling repo, a config file, or the PDF three folders over that was never in git. Scope the box to one repo and everything outside it is dark. Scope it to the machine and the box holds all 4.47 million files at once, with the option to narrow to a single folder when you already know where to look.
And it is fast enough that scope is cheap. A single filename lands in 85 microseconds (over a thousand times quicker than a blink) and a content query that took ripgrep 93.8 seconds on this machine returns in 16 milliseconds: long enough to read this paragraph, versus gone before you glance up.
Do it in one install
The setup, over MCP.
The whole-machine index connects to your agents through MCP, the open protocol agents use to call outside tools. One connector, read by every client. New to it? What an MCP server is, in plain English. The steps:
That is the entire difference from the per-repo playbook: you configure nothing per repo and nothing per tool. Point at the machine once, and every agent you already use inherits a fast, literal, always-current map of everything on it.
What one machine-wide index buys the agent
One index. Every agent. Always fresh.
The point of indexing the whole machine is not neatness: it is what the agent stops doing. Instead of grinding through directory listings and grep, it asks one question and gets an answer at memory speed. Measured on the same machine, watching a coding agent look for a single file: from 6 minutes 57 seconds and 71 tool calls down to 16 milliseconds and one call (seven minutes of grinding, or a single blink) and the share of session tokens spent hunting for files fell from ~58% to ~0%.
And because it already read every repo to build the index, it seeds a knowledge vault for free: on a fresh machine it replayed 8,455 git events in 1.7 seconds (the whole history, before the coffee finished) and drew 26,958 relationship pairs across the 12 repos it found, including two that quietly shared 435 identical files. That is the umbrella idea behind all of this: context acquisition is the bottleneck under every agent, and a machine-wide index is how you fix it.
MEASURED ON RYZEN 9 9950X3D · 64 GB DDR5 · NVMe · WINDOWS 11 · 4.47M FILES. NOT A REPLACEMENT FOR YOUR IDE'S INDEX, THE LAYER UNDER IT.
Questions people actually ask
FAQ.
Index the machine, not the repo
Give every agent one fresh map of your machine.
One signed installer indexes every file on your machine (names and contents, every repo plus the non-git 90%) and wires up the AI clients you already use over MCP. No JSON editing, no cloud account, no keys, and no per-repo re-indexing ever again. Keep your editor's index for what it does well; give every agent a fast, literal, always-current search alongside it.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · What Cursor's index can't see