SideNote ProUse AI with a local folder on your PC
This is the feature that changes what a desktop assistant is for. Instead of pasting files into a chat, you point SideNote Pro at a folder once and ask questions about it, with local search deciding what the model needs to see.
Adding and indexing a folder
- Add the folder explicitlyFrom the composer's folder action, or Settings, Local folders. Give it a display name you will recognise later. SideNote Pro never finds folders by itself.
- Let it indexSupported files are extracted and chunked locally. Indexing is asynchronous, so you can keep working, and cancellable from Settings. No AI provider is contacted at any point during indexing.
- Attach it to a conversationA visible folder chip appears in the composer. It stays attached to the thread until you remove it, so follow-up questions keep the same context.
- AskYour question triggers a local search first. Only then is a provider request built, carrying your question plus the excerpts that search selected.
- Check the sourcesA Sources expander on the response lists the files, and PDF pages, the excerpts came from, with Open and Reveal actions.
Refreshing an index is incremental. Relative path, size and last-write time are compared, so unchanged files are preserved, new and changed files are reparsed, and deleted files drop out. Re-indexing a large project after a day's work is fast.
What is sent, precisely
This is the part worth being exact about, because *AI that reads your files* could reasonably describe several very different architectures.
Never leaves your machine
The folder, the files, the extracted text, the index, the search query and the ranking. Indexes are stored DPAPI-protected under your Windows account. No embeddings are computed and no vector service is contacted.
Goes to your provider
Your question, plus up to ten selected excerpts, delimited as untrusted reference data, inside the ordinary Chat Completions request, after you press Send.
Folder-wide context is never sent. A 10,000-file folder does not become a 10,000-file prompt. Local retrieval selects a bounded set of excerpts that fits the remaining context budget, and that is all the model sees.
How retrieval decides what to send
Search is deterministic, case-insensitive BM25-style lexical ranking over excerpt text and relative filenames. It gathers a wider candidate set, limits how many chunks any single file can contribute so one large document cannot crowd out everything else, and selects up to ten high-ranked excerpts that fit the budget.
Filenames contribute to ranking, which matters in practice: a question mentioning auth will favour AuthenticationService.cs even where the term appears rarely inside it.
Because this is lexical rather than semantic, the vocabulary of your question matters. Ask about *session expiry* and it finds text saying *session expiry*. It will not bridge from *staff turnover* to a document that only says *attrition*. When a search misses, rephrasing in the material's own words usually fixes it faster than rephrasing the question more elaborately.
When nothing relevant is found, a no-result marker goes into the request telling the model not to claim folder support. That is a deliberate guard against invented citations.
Three worked examples
A code repository
Index the project folder. Generated and vendor directories such as .git, node_modules, bin, obj, dist and build are skipped automatically, so the index reflects your code rather than your dependencies.
Ask: *Where is authentication configured, and which files define session expiry?* Retrieval pulls configuration files and the relevant source. The Sources list is arguably more valuable than the answer: it tells you which four files to open, which is the actual question you had.
Product documentation
Index a folder of specifications and ask: *Which requirements mention offline behaviour?* This is tedious with file search because the phrasing varies across documents, and tedious to do by hand because it means reading all of them. Then follow up: *Do any of them contradict each other?*
Research notes
Index a folder of Markdown notes and PDFs and ask: *Find references to pricing assumptions and summarize the differences.* PDF chunks keep their page provenance, so a claim can be traced to a page and checked.
Getting better results
- Index a focused folder, not a whole drive. A folder scoped to one project retrieves better than one scoped to everything, because ranking has less noise to work through.
- Use the material's vocabulary. Lexical retrieval rewards matching terms.
- Ask one thing at a time. A compound question retrieves for a blurred average of both parts.
- Follow up in the same thread. The folder stays attached, and each follow-up runs its own retrieval with the new wording.
- Open the sources. Especially when the answer is surprising. It costs seconds and catches the case where retrieval found something that merely looked relevant.
- Refresh after significant changes. The index reflects the last time it was built.
Retrieval tells you what the model was shown. It does not tell you the model read it correctly, and it does not make the answer true. Treat a folder-assisted answer as a well-informed starting point with citations you can check, which is exactly why Open and Reveal are one click away.
Limits worth knowing
| Limit | Value |
|---|---|
| Files | 10,000 |
| Directories | 2,000 |
| Accepted source input | 512 MB |
| Chunks | 100,000 |
| Excerpts per request | Up to 10 |
Files that are unsupported, inaccessible, malformed, encrypted, empty or oversized are isolated and reported rather than failing the folder. Traversal never follows reparse points, junctions or symbolic links, and skips hidden and system paths. There is no OCR, so scanned PDFs contribute nothing. One folder attaches to a thread at a time.