Skip to main content
GET
Sessions
Returns the workspace’s recent sessions, newest first. A session is computed from the change feed when you read it: a run of changes by one account, through one agent key and one harness conversation, each within 45 minutes of the previous one. Nothing is started, ended, or stored, so there is nothing to open or close. Each agent write states a why (one sentence on what the person is trying to accomplish). A session reads like a git log: its steps are those whys in order, each followed by the changes made for it: what was done to which item, the versions it created, and the rows it wrote. Any member can read sessions (read). MCP: workspace_sessions. CLI: rip workspace sessions <workspace-id> [--cursor <cursor>]. Load returns the latest five sessions in the same shape. Auth: Authorization: Bearer tr_... (an account API key). {id} is the workspace UUID.

Query parameters

Response

How sessions are grouped

  • One read groups the most recent 1,000 changes you are allowed to see. A session too large for one reply is shortened (each change’s versions after its first, down to its first and last; then the oldest changes, then steps; each flagged), never refused. A session that crosses that boundary appears as two: the newer part, flagged earlierActivityNotShown, on this page, and the older part on a later page.
  • An external member sees sessions built only from shared changes. A session with no change they can see does not appear, and no internal reason, item, or count leaks.
  • Lease expiry and other system jobs form no session; they stay in the change feed.
  • A connector key gives no conversation id, so two parallel chats on one connector form one session; each change keeps its own why in the change feed.
  • Sessions disappear when activity retention prunes their changes. Handoff notes are ordinary artifacts and stay.

Errors