Searching transcripts from the console
The Search tab on the Sessions screen finds a hit and opens it in the replay player at the matched moment — a best-effort seek that works well for SSH, not for RDP.
Session transcripts and searching them covers the search itself in full — what is indexed, when, and the two raw API endpoints behind it. This article is the shorter, narrower one: the Search tab that puts that search inside the console, and specifically what happens when you open a hit.
The Search tab
On /pam/sessions, alongside Sessions and Evidence, there is a Search tab. Type a query and it calls the same full-text search the API exposes — Postgres full-text search over the English dictionary, so restarted finds restart. Each hit shows the matched fragment with your terms highlighted, so you can tell a relevant session from a coincidence before opening anything.
An "Open in player" action on a hit resolves the session and reuses the same reason-then-fetch replay flow every other recording uses — you are asked why you are viewing it, exactly as described in Session recording: what is captured, and that reason is recorded the same way.
Opening at the matched moment is best-effort
The search backend returns a matching session and a text fragment — a Postgres full-text-search row, not a position inside the recording. There is no stored offset to jump to. The console reconstructs one itself: once the recording has loaded, it looks for the matched fragment inside the concatenated text of the asciicast events and, if it finds it, opens the player at the offset of the event the fragment starts in.
What to do next
- Read what is actually indexed and how the query syntax behaves before you rely on a search returning nothing as proof nothing happened.
- For an RDP investigation, search by what you expect was typed or clicked, then use the player's own event list rather than expecting a seek to land on the moment.