Search
One query across six surfaces - issues, documents, chat, pull requests, code paths and agent tasks - because they all live in the same workspace.
Search is the payoff for the surfaces sharing a workspace. Looking for "retry budget" finds the issue that filed it, the spec that argued for it, the message where somebody noticed, the pull request that changed it, and the task an agent did about it - without you choosing a tool first.
Searching
The command palette in the app, or from the terminal:
$ rezee search "retry budget"
$ rezee search "retry budget" --surface issue,pull
$ rezee search "retry budget" --limit 50 --jsonAgents reach the same thing through the search MCP tool, which is what lets one look up what was concluded last time instead of keeping a private store nobody can audit.
The six surfaces
| Surface | What is indexed |
|---|---|
issue | title and body |
doc | title and body, and margin comments as hits of their own |
chat | message text |
pull | title and description |
code | file paths on the default branch |
task | delegated agent tasks and what came of them |
Code search is paths, not contents. A path index costs one listing per push; indexing contents would mean streaming every blob through the database on every push. So search "pipelines/index" finds the file and search "queueCiRun" does not.
Only the default branch is indexed. A feature branch's files are not what somebody searching a workspace means.
How it behaves
Queries are full-text, ranked, with the matching fragment returned as the snippet and the matched words marked in it. Ordinary web-search syntax works: quoted phrases, or, and a leading - to exclude.
retry budget # both words
"retry budget" # the phrase
retry or timeout # either
retry -timeout # retry, not timeoutThe index is written by the same request that wrote the thing indexed, not by a job that sweeps up later - so renaming an issue changes its hit on the next search, with nothing to wait for. Code paths are the one exception: they are refreshed on push, which is when they change.
What a scoped token sees
Each surface needs the capability its own endpoints need: issues:read, docs:read, chat:read, pulls:read, code:read, tasks:read. A scoped token gets the intersection of what it asked for and what it holds, so a token carrying only issues:read gets issues back and never learns a document title from a ranked list.
An unrestricted token and a browser session see everything the person can. rezee search prints which surfaces it was actually allowed to read in the footer, so a short result set explains itself.
A ws: resource scope still binds. Without that, "search everything" would have read across every workspace its owner happens to belong to.
