What and why?
harnesses_info knows where every harness stores sessions, but the tool surface stops at path metadata. Auditing this Pi session still required reading PI_SESSION_FILE with shell and hand-parsing JSONL. A multi-harness audit would repeat that work for Claude, Codex, SQLite stores, and different timestamp fields. The session registry is not usable as an agent data interface yet.
Possible approach
Add bounded read-only operations to list sessions by harness, project, and time, then read one session by a stable returned id. Keep the source path and embedded timestamps, paginate listings, cap message output, and distinguish an empty time window from an unreadable or unsupported store. JSONL adapters are enough for the first step; SQLite-backed harnesses can join behind the same normalized result later.
What and why?
harnesses_infoknows where every harness stores sessions, but the tool surface stops at path metadata. Auditing this Pi session still required readingPI_SESSION_FILEwith shell and hand-parsing JSONL. A multi-harness audit would repeat that work for Claude, Codex, SQLite stores, and different timestamp fields. The session registry is not usable as an agent data interface yet.Possible approach
Add bounded read-only operations to list sessions by harness, project, and time, then read one session by a stable returned id. Keep the source path and embedded timestamps, paginate listings, cap message output, and distinguish an empty time window from an unreadable or unsupported store. JSONL adapters are enough for the first step; SQLite-backed harnesses can join behind the same normalized result later.