Nit [CRF-1] Em-dash (U+2014) in the infinite scroll sentinel comment. (Netero)

{/* infinite scroll sentinel — sits 200px below the last thread */}

Predates this PR (blame ed908ed019, 2026-06-22) but sits in a file this diff modifies. make lint/emdash catches it; the AGENTS.md rule forbids the character in comments. Replace — with a period or restructure the sentence.

🤖

P3 [CRF-2] No events match your search. renders while hasNextPage may still be true, so the definitive negative is actually a mid-pagination snapshot. (Netero)

{isSearching && !hasAnyMatches && (
  <p ... role="status">
    No events match your search.
  </p>
)}

isSearching && !hasAnyMatches fires whenever the currently-loaded arrays yield no filter hits. While hasNextPage, the sentinel is still rendered below the message, the IntersectionObserver keeps firing onFetchNextPage, and matches can appear on the next batch. In the meantime the user reads a definitive negative that will lie if pagination stalls. Related to CRF-4: the fix suggested there (skip fetchNextPage() while isSearching) also resolves this, since then there is no next batch to wait for. Alternative: soften to "No matches so far." while hasNextPage, or hold the message until pagination drains.

🤖

P2 [CRF-3] Search-time summary override suppresses the server-truncation footer on the Agent Firewall audit surface; a search over a large session looks exhaustive when it is not. (Hisoka P2, Nami P2, Pariston P2, Mafuuu P3, Luffy P3, Zoro P3)

summary={
  isSearching
    ? {
        total: filteredNetworkCalls.length,
        blocked: filteredNetworkCalls.filter(
          (call) => !call.allowed,
        ).length,
      }
    : networkCallSummary
}
calls={filteredNetworkCalls}

network_call_logs is capped at 1000 per session server-side (enterprise/coderd/aibridge.go:54; comment: "Sessions past the cap need pagination to see the remainder"), and NetworkCallsList uses hiddenCount = summary.total - calls.length to render "Showing the first X of Y network calls" (NetworkCallsTable.tsx:65-79). That footer is the only UI signal the list is truncated.

While searching, this PR replaces both sides of the identity with the same filtered subset, so hiddenCount is always 0 and the footer never renders during a search. Consequences:

• Session with, say, 2,000 network calls (server returned the first 1,000). A query for a destination that lives in the truncated tail returns Network calls (0) or No events match your search. (the network panel is hidden by the filteredNetworkCalls.length > 0 guard at line 564). The operator concludes the call never happened.
• Same session, a query that hits 3 rows in the loaded prefix. Header reads Network calls (3), no truncation note, no indication the true match count could be many multiples higher.

This is the failure mode the truncation footer was added to prevent, on the audit surface where the answer to "did this destination ever appear?" has to be right. Keep networkCallSummary (or the true network_call_logs length) as summary.total during search so NetworkCallsList still emits the footer, or render a search-specific note like "N matches within the first M of Y loaded network calls." blocked can stay derived from filteredNetworkCalls.

🤖

P2 [CRF-4] The pre-existing pagination effect at line 461 (deps [hasNextPage, isFetchingNextPage, onFetchNextPage]) tears down and re-creates the IntersectionObserver on every isFetchingNextPage transition. IntersectionObserver.observe() delivers an initial notification with the current intersection state, so each re-attach fires the callback. When these new filteredThreads and filteredNetworkCalls empty out, the sentinel sits at the top of the panel and is always intersecting the 200px rootMargin. (Hisoka P2, Nami P3)

const filteredThreads = useMemo(...);
const filteredNetworkCalls = useMemo(...);
const hasAnyMatches =
  filteredThreads.length > 0 || filteredNetworkCalls.length > 0;

Sequence with a zero-match query on a paginated session:

1. Effect runs; sentinel is inside the 200px rootMargin because the only visible content is the "No events match your search." paragraph; callback fires -> onFetchNextPage().
2. isFetchingNextPage flips true; effect re-runs; new observer fires immediately; guard fails, no fetch.
3. Page returns; isFetchingNextPage flips false; effect re-runs; new observer fires; sentinel still intersecting; onFetchNextPage() fires again.
4. Loop until hasNextPage is false.

SESSION_THREADS_INFINITE_PAGE_SIZE = 20 (api/queries/aiBridge.ts), so a 400-thread session runs ~20 fetches back-to-back for a typo that yields no matches. Cheapest fix: skip fetchNextPage() while isSearching. Server pagination cannot help a client-only search anyway, and this also resolves the visible UX side of CRF-2 (the empty state no longer competes with in-flight pagination).

None of the new stories combine hasNextPage: true with an active searchQuery, so the play runs do not surface this. Add e.g. SearchNoMatchesWithNextPage: { hasNextPage: true, searchQuery: "no-such-event" } to make the cascade visible in Storybook.

🤖

P2 [CRF-5] Placeholder and aria-label promise a search scope the code does not deliver, and the visible columns tell the same lie. (Leorio P2, Pariston P3, Gon P2, Melody Note, Luffy Note)

placeholder="Search prompts, tool calls, and network calls"
aria-label="Search session events"

The placeholder sits above NetworkCallsTable, which renders method, proto, and matched_rule as visible columns (NetworkCallsTable.tsx:100,136,144). matchesNetworkCallSearch only checks call.detail, and the test suite locks that in: matchesNetworkCallSearch(call, "POST") -> false, matchesNetworkCallSearch(call, "allow api.github.com") -> false (sessionSearch.test.ts:88-91), and matchesThreadSearch rejects "claude-opus" and "anthropic" on the thread side. So an operator staring at a POST cell or an allow api.github.com matched-rule cell types the exact string they can see, gets "No events match your search.", and concludes the search is broken. It isn't broken; it lies about its scope.

Same drift shows up in the SessionTimelineProps.searchQuery JSDoc ("Search query applied across all event types") which the caller can't distinguish from the placeholder.

Pick one and mean it. Either widen scope so visible columns are searchable (add method, proto, matched_rule to matchesNetworkCallSearch; model, provider, server_url, etc. on the thread side), or narrow the copy to what actually matches, e.g. placeholder="Search prompt text, tool names, tool inputs, and network destinations" (and update the aria-label and JSDoc to match). The current aria-label ("Search session events") is the only hint a screen-reader user gets and is even vaguer than the placeholder.

🤖

Nit [CRF-9] Stale story comment: describes a "github.com" scenario but the story searches "npmjs.org". (Melody, Gon)

// While searching, the network panel header and rows reflect matches only.
// "github.com" appears in two of the mock calls (api.github.com and the DNS
// lookup for api.github.com), so the panel header shows the filtered count.

The story sets searchQuery: "npmjs.org" (line 191) and asserts Network calls (1) (line 194) with the npmjs row. Only netcall-2 (https://registry.npmjs.org/lodash) contains that substring; the count=2 github.com scenario the comment narrates does not run. Either rewrite the comment to match npmjs.org, or switch the story to searchQuery: "github.com" and assert Network calls (2).

🤖

Nit [CRF-10] Module doc cites Linear ticket AIGOV-462 in source. (Leorio, Gon)

/**
 * Pure session-search helpers. Matching is case-insensitive substring
 * matching over the strict field scope from AIGOV-462: prompt text, tool
 * names, tool input JSON, and network call destinations.
 */

grep -rn "AIGOV-" site/src returns exactly this hit; no other site/src file references Linear tickets. External readers cannot open it, and the sentence already enumerates the four fields. Drop from AIGOV-462; the ticket ref already lives in the PR description as Refs https://linear.app/codercom/issue/AIGOV-462.

🤖

Nit [CRF-11] onClear prop duplicates SearchField's built-in default. (Nami, Zoro)

onClear={() => setSearchQuery("")}

SearchField.handleClear already falls back to onChange("") when onClear is omitted (components/SearchField/SearchField.tsx). Every other in-tree caller (FilterPopover.tsx, ModuleSelectStep.tsx, MultiUserSelect.tsx, Chart.tsx) omits the prop. Drop the line; keep only onChange={setSearchQuery}.

🤖

Note [CRF-12] searchQuery state is not keyed by sessionId, so a query carries across direct URL-to-URL navigation between session detail pages. (Pariston)

const [searchQuery, setSearchQuery] = useState("");

The route /ai-gateway/sessions/:sessionId reuses this component, so the useState("") persists across sessionId changes. Recording this as a note because the in-app Back button unmounts the page; only direct URL-to-URL nav hits it, and clearing the field is one click. If session-to-session linking is added later, either add key={sessionId} on the timeline or reset searchQuery in an effect keyed to sessionId.

🤖

Note [CRF-13] Docstring calls the network scope "network call destinations" but the code matches against call.detail. (Zoro)

MockAIBridgeSessionNetworkCalls shows detail: "https://api.github.com/repos/coder/coder" for HTTP boundary logs; that means a search for /repos/ matches, which is wider than "destination" implies. Either tighten the comment to "network call detail (URL for HTTP, host for DNS)", or parse the URL host-only if the ticket really means destination. Prefer the doc fix unless the ticket says otherwise.

🤖