search: PR URLs with a review anchor, and why assistant anchors are not indexed

[grimmerk]

Question asked 2026-09-16: pasting a PR URL that carries a review anchor — https://github.com/<owner>/<repo>/pull/<N>#pullrequestreview-<id> — does it find sessions from both the prompts I typed and the messages Claude wrote? And would supporting more of this form cost CPU?

Answers below are measured against the live corpus, not reasoned from the code. Owner, repo, PR number and review id are written as placeholders throughout; the real ones are from a private work repository.

1. The anchor is already handled, and it is ignored correctly

PR_URL_RE ends with (?:[/?#].*)?$, so everything after the number is discarded:

parsePrRef('https://github.com/<owner>/<repo>/pull/<N>#pullrequestreview-<id>')
  = { number: <N>, repo: '<owner>/<repo>' }
parseQuery(same) = { words: [], prRefs: [{ number: <N>, repo: '<owner>/<repo>' }], fields: [] }

words is empty, so the anchor does not leak in as a stray term that would then have to match somewhere. The same rule covers the other tails GitHub produces (/pull/<N>/files, ?diff=split).

2. The PR number is found from both sides; the anchor only from prompts

One reference, every spelling, run through searchClaudeSessions:

query	sessions	where the match came from
…/pull/<N>#pullrequestreview-<id>	3	2 × prompt, 1 × assistant + prompt
…/pull/<N>	3	identical to the line above
<owner>/<repo>#<N>	3	identical
#<N>	4	one extra: a different repository's #<N>, which is what bare #N means
pullrequestreview-<id>	1	prompt only
<id> (the bare number)	1	prompt only

So the first half of the question is yes: a session is found through a reference Claude wrote, not only through one the user typed — that is the assistant reason, and it comes from the references mined out of assistant messages (#151).

The second half is the asymmetry worth knowing: the anchor id is findable only where the user typed it. Prompts are full-text searchable; assistant messages are not — only the canonical owner/repo#N references are extracted and stored. An anchor Claude pasted is therefore not findable by its id.

3. Extending the miner to index anchors would be nearly free, and is still not worth it

Measured by adding #(?:pullrequestreview|issuecomment|discussion_r)-?([0-9]+) as an optional group on the URL branch of PR_REF_RE, run over the largest transcript in the corpus with the miner's own extraction (assistant records only, tool inputs via JSON.stringify):

raw transcript	57.0 MB
assistant text actually scanned	2.2 MB (extracted in 73 ms)
current pattern	22.8 ms/pass, 2584 matches
with the anchor group	23.5 ms/pass, same 2584 matches, 22 carrying an anchor
difference	+0.8 ms per pass (+3.4%)

The structural point is the second row: the regex only ever sees about 4% of a transcript, and mining is incremental by byte offset afterwards, so even that 0.8 ms is not paid twice.

Recommendation: do not index anchors. The cost is not the reason; the value is. Anchors were 22 of 2584 matches (0.9%) in that session, and an anchor identifies a position inside a GitHub page rather than a session — searching the number already narrows to 3 sessions, and stepping to the exact moment inside one is what the ‹ 2/12 › hit navigation from #146 is for.

What would actually answer "find the session where that review link was pasted by Claude" is full-text search over assistant prose, which is #144's open question 8 and a much larger commitment (a searchable second copy of the corpus). Anchor indexing is a narrow special case of it and would not generalise.

Filing this as a record of the measurement rather than as work to do; close it if you agree with the recommendation.

🤖 On behalf of @grimmerk — generated with Claude Code