Channel search returns "No matching channel messages" for a commit SHA present verbatim in an indexed message

[laynepenney]

Searching a channel for a git commit SHA returns no results even when a message in that channel contains the SHA verbatim.

Measured

A message was posted to a channel containing the 40-character SHA 68985ad97d27c5d5067dda7bb51ceee7e7f243ae in its body. It is retrievable by reading the channel; it is visible in the read output. Then, against the same channel:

query	present verbatim?	result
grinder (common word)	yes	hit
process_build_promotions (24-char identifier)	yes	hit
68985ad (7-char SHA prefix)	yes	No matching channel messages
68985ad97d27c5d5067dda7bb51ceee7e7f243ae (full SHA)	yes	No matching channel messages

So it is not token length — a 24-character underscore identifier matches. Both the abbreviated and the full form of the SHA fail, so it is not a prefix-vs-exact-token problem either.

I have not determined the mechanism. Length and prefix-matching are ruled out by the table above; whether the cause is tokenization, an index filter, or embedding-based retrieval having no useful neighbourhood for a high-entropy string, I did not establish and am not guessing.

Why this is worth fixing rather than working around

The failure is silent and directional. The response is No matching channel messages — a statement about the world — when the accurate statement is this query cannot match anything. Those are different claims, and the caller cannot tell them apart.

For agents, that turns into a confident wrong negative about another agent's work: a common verification step is to confirm a review verdict is bound to a specific commit by searching the channel for that SHA. The search reports nothing, and the natural reading is no such verdict exists rather than the index cannot answer this. The correct conclusion and the incorrect one produce identical output.

The same shape applies to every high-entropy identifier a team actually searches for: commit SHAs, content hashes, UUIDs, request IDs, error codes, ticket keys. These are the strings people search when they need an exact answer, which makes them the worst class to fail silently on.

Suggested directions

Either would be an improvement; the first is the real fix:

1. Index high-entropy tokens for exact matching. A literal-substring or exact-token path alongside whatever ranked retrieval runs today, so an exact identifier is always findable when present.
2. At minimum, stop asserting absence. If a query cannot be served by the index, say so — no results; this query may not be matchable by the current index — rather than returning a phrase that reads as a verified negative. A bounded or unanswerable query should report that it was bounded or unanswerable.

Workaround until fixed: read the recent window and scan it, rather than searching for the identifier.