px0 brain ask - leaves a record: the inputs it resolved, the guideline versions it inlined, every tool call with its timing, and the outcome.
The list view
Newest first, one row per run:[write] marks any run that called a write tool - something that posted, commented, or sent. It is the fastest way to find the run that touched the outside world. A run started with --dry-run is labelled as a rehearsal, so a stubbed run is never mistaken for one that really posted.
Run ids are run_<UTC date>-<UTC time>-<random>, so they sort chronologically and never collide.
Failed rows are the only ones coloured, so a screen full of runs shows you its problems before you read a word of it. The header counts visible rows against the total, and the line under it names whichever filters are actually in effect - so you are never confused about why a run you expected is missing.
The detail view
Enter on a row shows the whole record:
logs.retention_days), so for an old run you will see not available -- log retention removed it instead. The record itself is kept far longer than the log, which is why the summary survives even when the verbatim prompt does not.
Guidelines inlined names each file with the version used, not just the filename. If a guideline changed after this run, that difference is visible right here - and it is the single most common explanation for “this used to work”.
Timings are per tool call, so a slow run tells you which connector was slow rather than leaving you to guess.
The same data without the TUI
Every view has a plain-text equivalent, which is what you want in a script or a pipe:runs list --running checks each in-flight marker against the process table before reporting it, so a run that crashed does not show up as one that has been going for days. runs cancel sends SIGTERM, which lets the run finalize its record as failed; --force sends SIGKILL instead, which leaves the record as it was last written, so reach for it only when the run is not responding.
runs open differs from runs output: output prints the text recorded on the run, open reads the file on disk, so it shows what is there now if something changed it since.
To apply retention outside the daemon’s nightly pass - the only way it happens at all on a store that never installs the daemon:
px0 runs list and the TUI’s list view render row text from the same formatter, so what you grep is exactly what you saw on screen. px0 runs with no terminal to draw on - piped, or in CI - falls back to that plain listing instead of failing.
Only the current store’s runs are listed. Records carry the store that produced them, which is what makes PX0_HOME isolate history even though logs.path defaults to one directory shared by every store on the machine. Records written before that stamp existed are shown rather than hidden.
--since takes a relative age: 12h, 7d, or 2w. A leading minus is accepted too, so the -7d the TUI suggests works here as well.
Reading a failed run
Failures are recorded, not discarded - px0 persists the record before reporting the error, so you can always go back and read what happened. Work through it in this order:1
Find it
2
Read the record
3
Read the prompt it actually sent
Open the run in
px0 runs and look at the rendered prompt. Guideline text that reads oddly, or an input that resolved to nothing, is usually visible immediately.4
Fix and confirm
Edit the workflow, then rerun by hand with
--dry-run before letting the schedule pick it up again.How long records are kept
Retention is applied by the daemon’s nightly pass. Without the daemon running, nothing is deleted.