Guides · updated July 2026
How to search code across every repo at once.
A function is defined in one repo, called from three others, and referenced in a script that was never committed. To find every use, you open each project and search it separately, then stitch the lists together in your head. Almost every tool (your editor, Cursor, even the command line) is built to look at one project at a time. Here is how developers actually search across repos today, exactly what each method can and can't see, and the one structural fix.
TL;DR · the short version
Key takeaways. Search every repo from one local index.
The problem is scope, not speed. Your editor, Cursor, and hosted code search each look at one project (or one server's pushed state) at a time, so a question that crosses repos becomes N separate searches you merge by hand.
One local index spans every repo plus the non-git files. Interlinked keeps a single always-fresh index of every file on the machine (names and contents), including the uncommitted edits and the files that were never in git.
Literal and exhaustive, with no model in the box. Content search across 4.47M files runs in the 1 to 10 ms range; the heaviest query that took ripgrep 93.8 s returns in 16 ms (58,625× faster), and filenames land in a 139 µs best case.
Always fresh, always cheap. A saved edit is searchable in about a millisecond, and the whole engine idles around 44 MB, so the index never lags your working copies and never leaves the machine.
Keep your per-repo tools; add the layer under them. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
The core problem, drawn
N repos, N searches. Or one query for all of them.
A per-repo tool draws a wall around one project. Ask a question that crosses those walls ("where is this used across everything I work on?") and you run the same search once per repo, then merge the results yourself. A single index over the whole machine collapses that into one query that reaches every repo, plus the files that were never in git at all.
The ~8 ms figure is the average of a five-query content search set, run on the test machine below over 4.47M files. The point of the picture isn't the number. It's the shape: the left side scales with how many repos you have; the right side doesn't.
The ways people do it today
Four ways to search many repos, and where each one stops.
None of these is wrong. Each was built for a real job and does it well. The only question is what each one can still see when your question crosses a repo boundary: spans every repo, includes the edits you haven't committed, and reaches the files that live outside git.
| Method | Spans repos | Your live edits | Non-git files | The catch |
|---|---|---|---|---|
| Open each repo (VS Code multi-root) | one at a time | yes | folders you add | you search, and merge, per project |
| grep / ripgrep loop over folders | if you script it | yes | yes | re-reads every byte each run: slow at scale, no ranking across repos |
| Sourcegraph | yes | no (pushed state) | no | runs on a server, configured per repo |
| Hosted code search (GitHub) | within an org | no (pushed state) | no | not the working copies on your disk |
| Interlinked (whole-machine index) | every repo | yes (live) | yes | one local index, handed to every agent |
Behaviours listed are the public, documented design of each tool: editor and command-line search walk the folders you point them at; Sourcegraph and hosted code search index the pushed state of repositories on a server. Nothing here is a bug. It's scope. The bottom row is the only one whose scope is the whole machine.
Anchor one · the local index
Cursor's index is scoped to the repo on purpose.
Cursor builds a genuinely good index of your code, one that understands meaning, so you can ask "where do we handle refunds?" and get the right function without knowing its name. That index is scoped to the one workspace you opened, and that scoping is correct: it keeps results relevant instead of drowning them in matches from unrelated code. But the boundary is real, and it explains why cross-repo search is hard everywhere, not just in Cursor.
The API, the mobile app, the shared library that all ship together sit in their own folders. The open workspace is indexed; the others aren't candidates.
That your dozen repos are one product is a fact between repos, not inside any one of them, so a per-repo index has nowhere to put it.
Configs, datasets, downloads, other tools' projects, the PDF with the answer. Most of a real disk was never in git, so it was never in the index.
Keep the index: it's the right tool inside the repo you're in. How Cursor indexes your codebase, and what it can't see →
Anchor two · cross-repo, with a catch
Sourcegraph does span repos. It also needs a server, and only sees what you pushed.
"Just index all the repos" is a solved problem at the organisation level. Sourcegraph builds a code graph across an org's repositories and is the right tool for a platform team searching a fleet of services. But it runs on a server, is configured per repository, and searches the pushed state, not the working copies open on your disk right now, and never the files that were never in git.
So the two anchors leave the same gap from opposite sides. Cursor sees one local repo in depth but not its siblings; Sourcegraph sees many repos but only their pushed, server-side reflection. Neither sees the machine you actually work on: the local, half-committed, part-git-part-not reality where the answer usually is.
On a fresh install, a whole-machine index found 12 of 12 repos on the disk and, from their own history (8,455 events replayed in 1.7 seconds), derived 26,958 relationship pairs, including the cross-repo fact that a folder of separate projects ships together. No server to stand up, no per-repo config, nothing pushed anywhere.
The fix · one index for the whole machine
Index every repo once. Query all of them at once.
Interlinked keeps one 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 a single connector. It is a fast, literal, exhaustive layer, not a semantic one: it answers "where does this exact symbol appear anywhere on this machine?" in the low-millisecond range, no matter how many repos that spans. Keep Cursor's meaning-index and any server search you run: this is the floor they stand on.
The alternative to one query is the scripted loop: grep or ripgrep walking every folder on every run. Across a five-query content set the indexed search ran 58,625× faster on this machine; on the heaviest single query, 93.8 seconds of ripgrep became 16 milliseconds. Filename lookups across the same 4.47M files land in a 139 µs best case. A saved edit is searchable in about a millisecond, under 30 ms worst case, so the index never lags your working copies. 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 CROSS-REPO CODE GRAPH IN THE CLOUD: THE LOCAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT AND EVERY REPO.
Common questions
Cross-repo search, answered.
QDoes this replace Cursor or Sourcegraph?
No. Keep them. Interlinked is the fast, literal, whole-machine layer beneath the tools you already use: Cursor keeps its meaning-index inside your open repo, Sourcegraph keeps serving your pushed fleet, and every agent gains one search that spans every repo plus the non-git files.
QHow does it search across repos without a server?
It keeps a single local index of every file on the machine, so one query fans out to every repo at once instead of running once per project. There is no server to stand up, no per-repo config, and nothing is pushed anywhere.
QDoes it see uncommitted edits and files that were never in git?
Yes. The index tracks your live working copies (a saved edit is searchable in about a millisecond), and it reaches the non-git files a repo index never holds: configs, datasets, downloads, other tools' projects.
QIs it really faster than a grep or ripgrep loop?
Yes, because it never re-reads the disk. Across a five-query content set the indexed search ran 58,625× faster on the test machine; the heaviest single query that took ripgrep 93.8 s returned in 16 ms, and filename lookups across 4.47M files land in a 139 µs best case.
QIs there any AI, and what does it cost?
There is no model anywhere in the box: it is an index, a hashmap and a path/id match, and the index never leaves your machine. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
Stop searching one repo at a time
Keep your per-repo tools. Add the machine-wide layer.
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, Sourcegraph keeps serving your pushed fleet, and every agent gains one fast, literal search that spans all of it: the sibling repos, the uncommitted edits, and the non-git files included. Then ask any of them "which repos do I have, and where is this used across them?" and see how much lived outside the wall.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · How the vault seeds itself