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 --json

Agents 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

SurfaceWhat is indexed
issuetitle and body
doctitle and body, and margin comments as hits of their own
chatmessage text
pulltitle and description
codefile paths on the default branch
taskdelegated 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 timeout

The 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.