Finding things
Search code and project knowledge
Find indexed source by meaning, exact text, symbols, paths, or patterns while routing history, documents, media, and repository questions to their proper evidence.
“where do we handle expired tokens?”
Files and lines, ranked by relevance.
“find every call to the legacy client”
Exact matches across the repository.
“why do we retry twice?”
The decision, not the code — because that's what the question was about.
You describe what you need to understand, not the retrieval algorithm. Your assistant decides whether the next evidence should come from source, project history, a document, media, repository activity, or the dependency graph. That evidence selection is one of the ways the partnership reduces micromanagement.
Two questions, routed for you
Code and project history are related, but they are not one undifferentiated index. Source questions go to the code search index. Decisions, documents, lessons, and captured sessions have their own knowledge and recall searches.
Your assistant chooses the right one from the question. "Where is this done?" searches source. "Why was it done this way?" checks decisions and history. A deeper investigation can use both, but a code search does not silently treat a conversation as source evidence.
How it decides what you meant
In an ordinary conversation, you don't pick a mode. A quoted phrase searches exactly; a path pattern matches files; a question searches by meaning; a symbol name can combine exact and semantic evidence.
Under all of it: meaning-based search finds refreshSession when you asked
about "expired tokens", and exact search finds the one line with the typo. You
need both, and picking manually is a tax.
Every source-search shape
Production search covers:
| Need | Search behavior |
|---|---|
| A normal question | Chooses an appropriate strategy from the query |
| Meaning plus exact evidence | Combines semantic and keyword retrieval |
| A concept described in plain English | Ranks source by semantic relevance |
| A quoted string or exact symbol | Prioritizes literal matches |
| A path, glob, or regular expression | Matches the requested pattern |
| Every occurrence | Returns a complete line-level sweep rather than a small ranked sample |
| A rename or symbol refactor | Finds usages with pagination designed for refactor work |
| Several team projects | Searches across the authorized project set |
| An implementation investigation | Returns raw evidence with a bounded explanation of where to work |
| A deeper multi-source investigation | Crawls across the relevant indexed evidence for complex questions |
The last two are for deliberate investigations, not a reason to make every lookup expensive.
Control the shape of the result
Ask for paths when you need a file set, a count when you only need the total, compact evidence when context is tight, or full snippets and metadata when you need to inspect the match.
Ordinary results can continue by position. Refactor results may return an opaque continuation marker; a client must pass it back unchanged with the same query and scope. “There are more results” is not the same as “the search was empty.”
Follow one bug from symptom to code
Suppose users are sent back to sign-in after a laptop wakes from sleep. Start with the symptom:
where do we handle an expired access token after the computer wakes?A meaning-based lookup can find the refresh coordinator even if no function is named “wake” or “expired access token.” From the returned paths and lines, ask for the exact provider error:
find every place we handle "invalid_grant"Then ask for every use of the legacy refresh client before replacing it. That last request needs a complete or refactor-safe result, not the first five ranked matches. If the change crosses modules, follow with a dependency-impact question rather than assuming text matches are all of the callers.
The useful output is a small evidence set: the refresh entry point, the stale token branch, the legacy client usages, and the relevant tests. It is not a generic explanation of OAuth and it is not permission to edit whichever file ranked first.
If you then ask “why do we retry only once?”, the assistant should leave source search and inspect project decisions or past sessions. The same investigation can use both kinds of evidence without confusing where with why.
Repository and media evidence
Linked GitHub, GitLab, and Bitbucket repositories can contribute code, pull request, issue, commit, and activity evidence when the question calls for it. That is different from searching only the locally indexed checkout. See Integrations and repositories.
Images, recordings, audio, and PDFs use their own extraction and search path. See Images, video, audio, and documents. A screenshot is not source code merely because it contains an error message.
Why it beats the agent grepping
Two reasons.
Speed. Existing source is pre-indexed, so a lookup can return ranked evidence without walking the repository one file at a time.
Cost. Every file the agent opens to check is input tokens. Ranked results mean it opens three files instead of thirty.
Indexing
The managed local sync helper watches validated project mappings and sends eligible changes for hosted indexing. Supported editor hooks and ContextStream Desktop can also request refreshes. A fresh clone needs an initial ingest; a newly created file can briefly outrun the index.
Ignored and secret-pattern files are excluded, with .contextignore available
for ContextStream-only exclusions. See
Privacy and what gets indexed.
An aging or stale index can still answer about existing indexed code. Refresh before concluding that a newly edited symbol is absent. A hosted gateway may report that the machine-local ingest path must handle the folder; that is a handoff to the local sync process, not an error to retry indefinitely.
Beyond text
"What would break if I change this" is a graph question, not a text one. See Code health and dependencies.
If it doesn't work
A file I just made isn't found. Indexing lag. Refresh the project index, then retry the narrow search. A local file read is still the source of truth for an unsynced edit.
Results are from the wrong repository. Two repositories share a project. See Workspaces and projects.
Nothing comes back. Check indexing has run. On a fresh project there may genuinely be nothing yet.
Only the first group of matches appears. The result may be paged. Continue from the returned position or refactor marker without changing the filters.
A “why” question returns only source lines. Ask for the decision or past session explicitly. Code search and durable knowledge are related evidence, not one interchangeable index.