Guides · updated July 2026
How to give Cursor whole-machine context.
Cursor is excellent inside the folder you opened, and completely blind to the other eleven projects on the same disk, the configs, the datasets, the PDF with the answer. You feel it every time you paste a file path into chat or re-explain a service that lives one folder over. Here is how to widen that circle: from a two-minute workspace tweak to a machine-wide index that every agent can share.
TL;DR
- →Cursor's index is scoped to the one workspace you open: brilliant inside that repo, blind to every other project and the non-git ~90% of your disk.
- →Four common workarounds (multi-root workspaces, @-mentions, symlinks, Sourcegraph) each widen the circle a little; each still misses the local, unpushed, or non-git reality of your machine.
- →The clean fix is a machine-wide index exposed over MCP: one connector that lets Cursor (and every other agent) search every file on the computer.
- →On a 4.47M-file machine a filename lands in ~85 microseconds; a content query that took ripgrep 93.8 seconds returns in 16 milliseconds.
- →It runs locally with no model in the box, sits at ~44 MB idle, and one install wires up 19 AI clients, not just Cursor.
Start here · the definition
First, what "whole-machine context" means.
Whole-machine context is the ability for an AI assistant to search and read every file on your computer (every repository, plus the roughly 90% of the disk that was never in git) instead of only the single folder you happen to have open.
Cursor doesn't have that, by design. When you open a project it builds a semantic index of that workspace: 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. Its boundary is just as real: the index stops at the folder you opened, and everything else is dark. We drew that mechanism in detail in how Cursor indexes your codebase.
The problem is that an agent's questions don't respect folder boundaries. "Which service calls this endpoint?" The answer might be in the API repo one folder over. "What did we decide about auth?" It's in a design doc that was never in any repo. To answer those, the assistant needs to see the machine, not the workspace. That's the gap every option below is trying to close. See also how to search across multiple repos.
The shape of the fix
Cursor's circle, and the layer you draw around it.
Keep Cursor's index, the white box. Whole-machine context is the acid field around it: the sibling repos and the non-git 90%, indexed once and handed to every agent through a single connector. Same layer, every tool, not a Cursor-only silo.
The API, the mobile app and the shared library that all ship together live in their own folders. Cursor indexes one; the layer covers all of them at once.
Documents, configs, datasets, downloads, other tools' projects, the PDF with the answer: the bulk of a real disk was never in git, so no repo index ever considered it.
The same machine-wide index answers for Cursor, Claude Code, Copilot and Codex through one install: no per-agent setup, no code leaving the machine.
Every option, honestly
Five ways to widen Cursor's reach.
Multi-root workspace. Add extra folders to the workspace and Cursor will index more than one root. Useful, but you have to know and open each folder by hand, it still only covers project folders, and the bigger index gets slower, and it's Cursor-only.
@-mention files or @Codebase. Pull a specific file, folder, or the codebase into a single prompt. Precise, but manual and per-prompt: you have to already know where the thing lives before you can point at it.
Symlink the other repos in. Junction or symlink sibling repos into the open workspace so Cursor sees them. It works, but it's fragile, pollutes the tree, still ignores everything non-git, and breaks the moment folders move.
Sourcegraph or a hosted code graph. Index many repos org-wide. The right tool for a platform team, but it runs on a server, is configured per repo, and only sees the pushed state, not your local working copies or non-git files.
A machine-wide index over MCP. Keep one always-fresh index of every file on the machine (names and contents) and expose it to Cursor and every other agent through a single connector. Whole machine, every repo, the non-git 90%, in microseconds.
| The approach | What it can reach | Setup | Which agents |
|---|---|---|---|
| Multi-root workspace | a few folders you add by hand | manual, per project | Cursor only |
| @-mention / @Codebase | whatever you point at, per prompt | every prompt | Cursor only |
| Symlink sibling repos in | linked git folders | fragile hack | Cursor only |
| Sourcegraph | many repos (pushed state) | server + per-repo | its own UI |
| Machine-wide index over MCP | every repo + the non-git 90% | one install | all 19 |
Options 1 to 3 keep everything on your machine but stay inside Cursor and inside git. Option 4 crosses repos but adds a server and a push requirement. Option 5 is the only row that covers the whole disk and feeds every agent, compared head-to-head in Sourcegraph vs local search.
The cross-repo option, and its catch
Sourcegraph already searches many repos. It runs on 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 lives 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 the two famous anchors leave the same gap from opposite sides. 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 here, a whole-machine index found 12 of 12 repos on the disk and read 8,455 git events in 1.7 seconds (less time than it takes to read this sentence) to seed 26,958 relationship pairs, unprompted spotting two repos that shared 435 identical files. That cross-repo fact (that a folder of separate projects ships together) is something neither a per-repo embedding index nor a pushed-only code graph can even represent. Why this layer is the bottleneck →
The whole-machine layer
Index the machine once. Hand it to every agent.
Interlinked is the acid field 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. Complementary to the embeddings: the floor the meaning-index stands on.
SET IT UP · THREE STEPS
Install once. One signed installer indexes every file on the machine (names and contents) and auto-configures 19 AI clients, Cursor included. No JSON editing, no cloud account, no keys.
Keep Cursor's index. Nothing to disable. Cursor's semantic search keeps running on your open repo; the machine-wide layer answers the literal, whole-disk queries alongside it. A save is searchable in about a millisecond.
Ask across everything. In Cursor's chat, ask about a file in another repo, a config, or a PDF. It resolves in microseconds. The same layer now answers for Claude Code, Copilot and Codex too.
NOT A REPLACEMENT FOR CURSOR'S INDEX: THE LITERAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT, CURSOR INCLUDED.
Questions people ask
Cursor context, answered.
Can Cursor search across multiple repositories?
Not on its own. Cursor's index is scoped to the workspace you open. A multi-root workspace lets it read a handful of extra folders you add by hand, but it still won't reach folders you didn't open, and never the non-git files on the disk. A machine-wide index exposed over MCP removes the boundary entirely.
Does giving Cursor more context send my code to the cloud?
It depends how. Cursor's own semantic index computes embeddings on its servers, so those chunks leave the machine. A local whole-machine index like Interlinked never leaves the machine and has no model in the box: it is a literal index and a lookup, not an inference engine.
How is this different from Sourcegraph?
Sourcegraph builds a code graph across many repositories, which is the right tool for a platform team, but it runs on a server, is configured per repo, and sees the pushed state, not the working copies on your disk or the files that were never in git. A local machine-wide index sees the disk exactly as it is right now.
Do I have to give up Cursor's index to do this?
No. Keep Cursor's semantic search for the repo you're in. It's genuinely good at meaning-based lookups. The machine-wide layer runs alongside it and answers the literal 'where does this exact string live on the whole disk?' questions Cursor was never scoped to answer.
How fast is a whole-machine search?
On a 4.47-million-file test machine, a filename lands in about 85 microseconds and a content query that took the command-line tool ripgrep 93.8 seconds returns in 16 milliseconds. A file you just saved is searchable in about a millisecond.
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.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · How Cursor indexes your codebase