Interlinked.

Explainers · updated July 2026

How Cursor indexes your codebase, and what it can't see.

Open a project in Cursor and it quietly builds an index of your code, not a list of filenames, but a map of what the code means, so you can ask "where do we handle refunds?" and get the right file without knowing its name. It is a genuinely good piece of engineering. It also has a boundary you can draw on a napkin: it stops at the folder you opened. Here is exactly how it works, and where the edge falls.

TL;DR · The short version

  • 01Cursor's index is semantic and genuinely good, but scoped to the one folder you open: it embeds your code into vectors on Cursor's cloud, then stops at that workspace's edge.
  • 02That leaves most of your machine dark: the sibling repos that ship together, and the non-git ~90% (documents, configs, datasets, downloads) that was never in git. The vectors also live in Cursor's vault, unreachable by Claude Code, Codex or Copilot.
  • 03Interlinked indexes the whole machine instead (4.47M files, every repo plus the non-git 90%) and hands the same literal index to every agent through one connector. No model, no cloud, and it never leaves the machine.
  • 04It is fast: a single filename lands in 85 µs (139 µs median across 4.47M files), about 412,000× faster than VS Code search, while content search runs ~7 to 9 ms where ripgrep took 93.8 s → 16 ms. Idle ~44 MB, and a saved edit is searchable in ~1 ms.
  • 05It does not replace Cursor's embeddings: it is the literal, whole-machine floor under every agent. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.

The mechanism, drawn fairly

An index of meaning, not of filenames.

"Indexing your codebase" is a specific pipeline. Cursor scans the workspace you opened, splits each file into chunks, and turns every chunk into an embedding, a long list of numbers that places the code's meaning as a point in space. Similar ideas land near each other, so a plain-English question can find code that shares no keywords with it. The embeddings are computed on Cursor's servers and stored as vectors in a remote database; a change-tracking hash tree means only edited files get re-embedded.

1 · WORKSPACEthe one folder you opened in CursorON YOUR MACHINE2 · CHUNK + TRACKfiles split into pieces; a hash tree flags only what changedON YOUR MACHINE3 · EMBEDeach chunk becomes a vector, its meaning as coordinatesSENT TO CURSOR CLOUD4 · VECTOR STOREvectors + obfuscated paths kept in a remote databaseCURSOR CLOUD5 · SEMANTIC SEARCHyour question finds the nearest vectors; chunks go to the modelAT QUERY TIME

Steps 3 and 4 run off your machine: code leaves to be turned into vectors, and Cursor's Privacy Mode changes what is retained there. Indexing honours .gitignore and .cursorignore, so anything you exclude is never chunked in the first place. All of this is public in Cursor's own docs, and all of it is scoped to a single workspace.

Credit where it is due

For the repo you're in, it is very good.

This is not a takedown. Semantic search over an open repo is exactly the right tool for the job it was built for, and Cursor does it well. Three things it genuinely nails:

Meaning, not spelling

Ask in plain English and get the right function even when you don't know what it's called, the whole point of embeddings.

Scoped, so it stays relevant

It only reads the project you opened, so results don't drown in matches from unrelated code.

Fresh as you type

The change-tracking hash tree re-embeds only what you edited, so the index keeps pace with your work.

Keep it. Nothing below asks you to give up Cursor's index. The point is only that "the repo you opened" is a small circle drawn on a much bigger machine, and everything outside that circle is dark.

The edge, on a napkin

The index stops at the folder you opened. Everything else is dark.

A workspace-scoped index is the correct design for an in-editor assistant. It is also, by construction, blind to most of your machine. Draw it to scale (one lit box inside the whole field) and the structural limit becomes obvious.

WHAT INTERLINKED INDEXESthe whole machine · 4.47M files · every repo + the non-git 90%REPOS ON THIS MACHINE: THEY SHIP TOGETHERapp-webopen in CursorINDEXED BY CURSORapi-servernot indexed by Cursormobile-appnot indexed by Cursorshared-uinot indexed by Cursor↑ the repo Cursor lit up↑ sibling repos on the same disk, dark to CursorTHE NON-GIT ~90% OF THE DISK: IN NO REPO INDEX AT ALLDocuments & PDFsConfigs & .env filesDownloadsOther tools' projectsDatasets & logsNotes & screenshotsCursor: the one repo you openedInterlinked: the whole field, fed to every agent
The sibling repos

The API, the mobile app, the shared library that all ship together live in their own folders. Cursor indexes one workspace; the others stay dark, and “these repos ship together” is a fact no per-repo index can even hold.

The non-git ~90%

Documents, configs, datasets, downloads, other tools' projects, the PDF with the answer. The bulk of a real disk was never in git, so it was never a candidate for the index.

It's Cursor's, in Cursor's vault

The embeddings live in Cursor's remote store, reachable only from Cursor. Claude Code, Codex and Copilot can't query them: every agent that isn't Cursor starts from nothing.

Cross-repo already exists, with a catch

Sourcegraph sees many repos. It also needs a server, and only sees what you pushed.

"Just index all the repos" is a solved problem at the org level. Sourcegraph builds a code graph across an organisation's repositories. Powerful, and the right tool for a platform team. But it runs on a server, has to be configured per repo, and sees the pushed state, not the working copies sitting on your disk right now, and never the files that were never in git.

So both anchors leave the same gap. Cursor sees one local repo but not the others; Sourcegraph sees many repos but not the local, unpushed, non-git reality of the machine you actually work on. The layer nobody indexes is the one closest to you.

On a fresh install, a whole-machine index found 12 of 12 repos on the disk and seeded 26,958 relationship pairs from their own history, including the cross-repo fact that a folder of separate projects ships together, which neither a per-repo embedding index nor a pushed-only code graph can represent. How the vault seeds itself →

The layer under all of them

Index the whole machine. Hand it to every agent.

Interlinked draws the outer box in the diagram. It keeps an always-fresh index of every file on the machine (names and contents) across every repo and the non-git 90%, and exposes it to whatever agent you use through one connector. It is not a semantic index and doesn't try to be: it is the fast, literal, exhaustive layer that answers "does this exact string exist anywhere on this machine?" in the time Cursor takes to notice you pressed a key. Different job, complementary to the embeddings: the floor the meaning-index stands on.

4.47M
files kept indexed across the whole machine: every repo plus the non-git 90%
139 µs
median filename lookup across those 4.47M files (a single file lands in 85 µs)
19
AI clients auto-configured in one install: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest

That lookup takes VS Code's own search about 35 seconds on the same machine (412,000× slower), and Windows Search a median 67 seconds (~480,000×). Content search runs in the ~7 to 9 ms range: a query that took ripgrep 93.8 s here returns in 16 ms. A saved edit is searchable in about a millisecond, under 30 ms worst case. At rest the whole engine sits around 44 MB in Task Manager, and the index on disk stays under 1% of the drive. It never leaves the machine, and there is no model anywhere in the box.

NOT A REPLACEMENT FOR CURSOR'S INDEX: THE LITERAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT, CURSOR INCLUDED.

FAQ · Common questions

The short answers.

Does Cursor send my code to the cloud to index it?

Yes. The embedding step runs on Cursor's servers, so chunks of your code leave the machine to be turned into vectors, then live in Cursor's remote database. Indexing honours .gitignore and .cursorignore, and Privacy Mode changes what is retained, but the vectors themselves sit in Cursor's vault, reachable only from Cursor.

Can Claude Code, Codex or Copilot use Cursor's index?

No. The embeddings are keyed to Cursor's own store, so every other agent starts from nothing. That is the gap a neutral, local, whole-machine index fills: one connector hands the same search to whatever agent you use.

Does Interlinked replace Cursor's semantic search?

No. It is complementary, and you should keep both. Cursor's embeddings answer what the code means inside the repo you opened; Interlinked is the fast, literal layer that answers whether an exact string exists anywhere on the machine, across every repo and the non-git 90%.

How fast is a whole-machine index, and won't it hog resources?

A single filename lands in about 85 µs (139 µs median across 4.47M files, roughly 412,000× faster than VS Code's search), and content search runs in the ~7 to 9 ms range where ripgrep took 93.8 s → 16 ms. At rest the engine sits around 44 MB, and a saved edit is searchable in about 1 ms.

What does it cost, and is there an AI model inside it?

There is no model anywhere in the box, and the index never leaves your machine: nothing is uploaded unless you publish a project or a link. Everything local, including the MCP connector every client plugs into, is free forever, no card. Hosting starts at $5.99/mo.

Give every agent the whole map

Keep Cursor's index. Add the rest of your machine.

One signed installer indexes every file on your machine and wires up the AI clients you already use: no JSON editing, no cloud account, no keys. Cursor keeps doing what it does well inside your open repo; every agent gets a fast, literal, whole-machine search alongside it. Then ask any of them "which repos do I have, and how do they relate?" and see how much lived outside the circle.

Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · Why context acquisition is the bottleneck

Measured July 2026 · Ryzen 9 9950X3D · 4.47M files · Windows 11← All research