SideNote ProAsk AI questions about a local folder
Add a folder you choose, and SideNote Pro indexes it on your machine. When you ask a question, local search picks the passages that matter and sends only those to your provider, with sources you can open. No embeddings, no vector database, no hosted search.
How it actually works
Most retrieval features are vague about what leaves your machine. This one is worth understanding precisely, because the design is unusual and the privacy properties follow directly from it.
- You add a folder explicitlyFrom the composer or Settings, Local folders. You give it a display name. SideNote Pro never discovers folders on its own, never crawls drives and never inspects recent files.
- Indexing runs locallySupported files are extracted and chunked on your machine. No AI provider is called at any point during indexing. It runs asynchronously and can be cancelled from Settings.
- You ask a questionWith the folder chip visible in the composer, your question triggers a local search over the index before anything is sent anywhere.
- Local search picks the passagesDeterministic BM25-style lexical ranking over excerpt text and relative filenames. It gathers a wider candidate set, limits how many chunks come from any one file, and selects up to ten high-ranked excerpts that fit the remaining context budget.
- Only those excerpts are sentThe ordinary provider request carries your question plus the selected excerpts, clearly delimited as untrusted reference data. The folder itself is never uploaded.
- The answer keeps its sourcesA Sources expander records which file, and which PDF page, each excerpt came from, with Open and Reveal actions when the file is still there.
Lexical retrieval, and why we say so
SideNote Pro uses BM25-style lexical ranking. It matches on the words in your question against the words in your files and filenames, weighted by how distinctive those words are. It does not use embeddings, a vector database, a hosted search service, or a model-generated query.
That is a real tradeoff and it deserves stating rather than glossing. Lexical search will not connect a question about *staff turnover* to a document that only ever says *attrition*. Semantic search would. In exchange you get retrieval that is deterministic, fast, requires no embedding model, involves no network call, and cannot leak your corpus to an embedding API.
Practical consequence: use words your documents are likely to use. Asking about session expiry finds the code that says session expiry. If the first search misses, rephrase with the vocabulary of the material rather than the vocabulary of the question in your head.
What gets indexed
PDF, DOCX, TXT and Markdown are extracted using the same pipeline as document attachments, alongside a conservative set of bounded plain-text code and configuration extensions including .json, .xml, .csv, .yaml, .md, .cs, .ts, .tsx, .js, .py, .java, .go, .rs, .sql, .html, .css, .ps1 and .sh.
Generated and vendor directories are skipped so an index of a code repository stays useful rather than drowning in dependencies: .git, .svn, .hg, .vs, .idea, node_modules, bin, obj, packages, .nuget, .gradle, dist, build, coverage and .cache. Hidden and system paths are skipped, and traversal never follows reparse points, junctions or symbolic links.
| Limit | Value |
|---|---|
| Files | 10,000 |
| Directories | 2,000 |
| Accepted source input | 512 MB |
| Chunks | 100,000 |
| Excerpts selected per request | Up to 10 |
Files that are unsupported, inaccessible, malformed, encrypted, empty or oversized are isolated and reported rather than failing the whole folder. Refreshing compares relative path, size and last-write time, so unchanged files are preserved, new and changed files are reparsed, and deleted files are removed from the index.
What people use it for
A code repository
Index a project folder and ask *Where is authentication configured, and which files define session expiry?* Retrieval pulls the configuration and the relevant source, and the Sources list tells you which files to open next. Useful on a codebase you did not write.
Product documentation
Index a folder of specifications and ask *Which requirements mention offline behaviour?* This is the kind of question that is tedious to answer with file search because the phrasing varies across a dozen documents.
Research notes
Index a folder of Markdown notes and PDFs and ask *Find references to pricing assumptions and summarize the differences.* The summary is only as good as the excerpts retrieved, which is exactly why the Sources list exists.
What retrieval does not prove
A Sources list tells you which excerpts were placed in front of the model. It does not tell you the model read them correctly, and it does not make the answer true. Retrieval narrows what the model is working from; verification is still yours to do, which is why Open and Reveal are one click away.
When local search finds nothing relevant, a no-result marker goes into the request telling the model not to claim folder support for its answer. That is a deliberate guard against the failure mode where a model confidently invents a citation.
Only one configured folder attaches to a thread at a time, and it stays attached until you remove the visible composer chip. The full guide is at using AI with a local folder.