Skip to content
English

Command and statement records

A recording answers what happened, but it cannot be searched. Command records exist as the index for searching and locating: find a command across sessions, then jump back to that connection at that moment.

Records come from two places. Command line content is reconstructed from terminal output, where the recording is the source of truth; query console statements are registered as they are sent, so they are the source of truth themselves.

The Command Audit page searches across sessions, filtering by:

  • A keyword, matched as a substring of the command text.
  • Source: the query console or the command line.
  • Target database.
  • Result state (several at once) and the target’s error code.
  • User, asset, and time range.

An action on the row jumps straight to that connection and positions playback at the moment of that record.

The command list for a single session is on the session detail page, where a note on the section says the content is reconstructed from the keystroke stream and the recording governs; for a console session the note says statements are registered as they are sent.

The server’s output stream feeds a virtual terminal screen, and the current line is captured when the user presses Enter. This reflects backspaces, Tab completion, and history recall correctly, because it reads what actually appeared on the terminal. SSH, the database command line, and container exec use the same reconstructor.

In MySQL and PostgreSQL sessions, a SQL statement spanning continuation lines accumulates into one complete record, settled when a semicolon or a meta-command arrives, so SELECT\n1 AS\nx; is one record rather than three. A meta-command and the query after it stay separate. Redis and SSH stay line by line. SQL Server splits on the batch terminator, and prompts stay out of the command text.

Each execution unit gets a unique event identifier and carries the result facts: target database, result state, reason code, rows returned, rows affected, number of result sets, the target’s error code, elapsed time, and whether it was truncated. The values a result state can take are pinned by a database constraint, covering running, succeeded, error, blocked, canceled, timed out, partially applied, and result unknown.

Visible echoed input produces a searchable command record or an explicitly downgraded record. Input without echo leaves no command-text record; the recording is the source of truth for text sessions. An agent command blocked before reaching the target remains in the recording and tool ledger, not in ordinary command records. When it cannot be reconstructed with confidence, what is produced is a clearly marked downgraded record holding no guessed text. The interface marks each one as content that cannot be reconstructed and offers a way to the recording of that stretch, and a banner above the section says how many rounds in the period could not be reconstructed and that a keyword search does not cover them.

The downgrade itself can raise an alert, presented under its own category on the alerts page.

Command text is the index, and the connection recording is the source of truth. Where they disagree, the recording governs. Console statement records are the exception: they are the source of truth themselves, the transcript recording is derived from them, the two correspond through the event identifier, and where they conflict the structured record governs.

  • Each record holds a sequence number, the command or statement text, the execution time, the session it belongs to, the user, and the asset.
  • Console records also hold the result facts above, and a cross-session search can filter on those fields directly.
  • Downgraded records are clearly marked, and their number is visible in the interface.
  • The command CSV in an evidence bundle covers these fields, with the result columns left empty for text terminal records; see Evidence bundles and event reports.