Ask your code what it is, not what it was called
You know the feature exists. You wrote it, or somebody did, in one of nine repositories on this disk. You do not know the filename, and neither does grep.
Press ⌃⇥ in the search window and results switch to code only. Describe the file — component where the streak is shown in a sheet — and it returns the file that does that, across every repository on the disk, even when the file contains none of those words. Everything is indexed and ranked on your Mac.
The search you cannot express as a string
grep is the right tool roughly half the time and it is unimprovable at that half: you know the string, you want the files containing it, you get them. The other half is the one that costs an afternoon. You remember what a piece of code did, and the words you would use to describe it are not the words in it. The file is called DashboardStreakSheet.tsx; you are searching for “the thing that shows the streak when you tap the header”. Nothing you type matches.
Four things that make the results usable
Descriptions, not strings
Queries are matched on meaning as well as words, so a description of behaviour finds the file that implements it. This is the whole point, and it is also the part that only works because the rest of the list below is true.
Identifiers are read as words
showStreakInSheet is split into show streak in sheet before anything is indexed. Half-remembered fragments therefore land: you do not have to reproduce the casing, the separator or the exact compound somebody chose at four in the afternoon.
Declaring beats mentioning
A file that defines a symbol is ranked substantially above a file that merely refers to it. Without that, every search for a component returns its Storybook story, its test, and four files that import it, with the component itself somewhere below the fold. It is a strong ranking preference rather than an absolute rule — a test that is genuinely the best match still surfaces.
The noise is not indexed at all
node_modules, lockfiles, sourcemaps, minified bundles and build output are skipped deliberately. So is anything inside .git. This is not a filter applied to results — those files are never opened, which is also why indexing a repository is quick.
Code stays out of the way until you ask for it
On a developer's Mac the overwhelming majority of files are repository source. If those appeared in ordinary results, every search for a bank statement would return four hundred TypeScript files, so they do not: everyday search behaves as though the repositories are not there, and ⌃⇥ flips the whole window into code. One keystroke, both worlds, no settings to configure.
It runs on your machine, which is the part that matters at work
Reading, embedding and ranking all happen locally, and search works with the network off. No source is uploaded, no repository names are transmitted, and there is no account to attach any of it to. For code that belongs to an employer, that is usually the difference between a tool you may install and one you may not.
What it is not
It is not an assistant and it will not explain your code, write it, or answer questions about it. There is no chat window. It returns a list of files with one line saying why each one matched, you press Return, and the file opens. That is the entire interaction, and it is deliberate — you already know what you want to do with the file once you have found it.
Questions people ask about this
How is this different from grep or ripgrep?
grep answers “which files contain this string”, perfectly and instantly, and you should keep using it when you know the string. This answers “which file is the one that does X”, which grep cannot do, because the file that does X frequently contains none of the words you would use to describe X.
How is it different from my editor’s “go to file” or “find symbol”?
Those need the project open and need you to know roughly what the thing is called. This works across every repository on the disk at once, from anywhere, and takes a description rather than a name — useful in the situation where you know a feature exists and cannot remember which of nine repositories it lives in.
Does it index node_modules and build output?
No, on purpose. node_modules, lockfiles, sourcemaps, minified bundles and compiled output are skipped. Nobody has ever wanted a search result from a vendored dependency, and indexing them would drown everything you did want.
Which languages does it understand?
Hundreds — everything from Vue and Svelte to COBOL — because language detection and symbol extraction are driven from a table of grammars rather than a hand-picked shortlist. Everyday retrieval works across all of them; how much structure is recognised varies by language.
Why is my code hidden from ordinary search results?
Because on a developer’s disk most files are repository source, and somebody hunting for a receipt does not want six thousand of them. Code lives in its own scope: press ⌃⇥ in the search window and results flip to code only.
Does my source code get uploaded anywhere?
No. Indexing, embedding and ranking all happen on your Mac, and search works with the network off. For code belonging to an employer that is usually the difference between being allowed to use a tool and not.
Describe the file. Press Return.
Index the repositories you actually work in, hit ⌃⇥, and describe something you remember writing. Seven days, no card, nothing uploaded.
- Apple silicon · macOS 26 or later
- No account
- Nothing leaves your Mac