Session Logs give every Baz run a structured execution record. They show how a run was triggered, where it executed, its current state, major completed stages, outcome, and cost. Instead of exposing raw internal logs, Baz presents a timeline of product events so teams can inspect reviewer runs, fixer runs, scheduled scans, benchmark runs, and future Codex or Claude Code workflows from one place.
When Baz reviews a pull request, the visible output is usually a comment, a check, or a completed status. That works when everything completes cleanly. It is less useful when the run is still in progress, delayed, skipped, or failed before publishing anything back to the pull request.
Session Logs give each Baz run a structured record in the product. They show how the run was triggered, where it executed, what state it is in, which major stages completed, what outcome was produced, and what the run cost. The goal is to make Baz activity inspectable without exposing raw internal logs.
The Sessions page lists recent runs across Baz workflows. It includes status, environment, trigger source, pull request author, and cost, so teams can find failed, queued, scheduled, or expensive runs without reconstructing state from GitHub checks or comments.
The session detail page presents the run as a timeline of product events. Instead of showing low-level logs, it groups the run into meaningful stages such as setup, review, findings, publishing, completion, or failure. This gives users enough context to understand whether Baz is still working, completed without publishing, stopped at a specific stage, or produced findings that were later sent back to the pull request.
Underneath, Baz now stores reviewer session events as first-class records with metadata, payload, expiration defaults, and indexes for execution, pull request, and expiry queries. The read path exposes session lists and session details by querying session metadata and events, then projecting them into structured steps for the UI. The event model carries canonical event types, entrypoint information, severity counts, reviewer details, and skip or error metadata, giving the UI enough structure to explain the run consistently.
This is especially useful for partial states. A running session can show the latest completed stage. A failed session can show whether the failure happened before review, during review, or while publishing. A completed session can show what Baz did even when no pull request comment was necessary.
Session Logs also create a common model for future Baz workflows. Reviewer runs, fixer runs, scheduled scans, benchmark runs, and workflows powered by Codex or Claude Code can all be represented as sessions with an origin, status, environment, timeline, outcome, and cost.
The result is a more practical way to operate Baz at scale: each run has a durable record, and the product can explain what happened without requiring users to inspect infrastructure logs or infer state from scattered pull request signals.
.png)
.png)
