Diagnostics & the Flight Recorder

The app keeps a built-in flight recorder — a running record of what it's doing: server
log messages, agent-loop problems, tool calls and their outcomes, failed runs, every
HTTP request, and WebSocket activity. It's stored in its own dedicated local log files so
this firehose never slows down normal data, and each record is tagged so a log line links
back to the exact conversation step it came from.

You read it in Admin Tools → Diagnostics, a filterable (and optionally live) feed.
There's also a standalone diagnostics page that keeps working even if the main app's
interface is broken — handy for debugging, since it only needs the server's API to be
alive and can even be pointed at a remote server.

Two related captures can be switched on: a client render recorder (what the browser
saw — DOM snapshots, JS errors, slow network) and auto-investigation, where a failed
run is automatically handed to the Diagnostic Agent to look into.

Agents themselves can read the recorder via the Diagnostics ability (see
Abilities) — that's how the Diagnostic Agent diagnoses the running app.

The Server-Manager assistant can drive this whole loop itself when it's chasing a
visual or browser-side problem: it switches the client render recorder on, reproduces the
behaviour, reads back what the browser actually rendered — page snapshots, slow network
calls, JavaScript errors — and switches it off again. That lets it prove a UI fix worked
without asking you to watch the screen. See The Server-Manager TUI & Launchers.