How Long Work Survives: Sessions, Checkpoints, and Delegation
PI-Desktop's promise of long-running work depends on more than keeping a chat window open. The real question is which parts of a coding task remain trustworthy when the transcript grows, the model reaches its context limit, the user switches sessions, or a local process disappears. This chapter separates durable history, model-facing context, transient interface state, queued user intent, and delegated reports so the reader can form realistic expectations about continuity.
What survives is not all the same state
Start with the developer's repository investigation. The session contains the original question, the Agent's visible explanations, tool calls, command results, edits, and perhaps a review card for the resulting change. PI-Desktop treats that record as user data. Rust host-core owns the SQLite index and the session transcript store, while the substantial message content lives in a human-readable JSONL file for that session. SQLite can answer fast questions about sessions, turns, message ordering, artifacts, notifications, and search. It is not the only copy of what the user said or what the Agent observed.
That choice separates two kinds of durability. The JSONL transcript is the payload: it keeps structured blocks for final text, thinking, tool calls and results, attachments, and context checkpoints. SQLite is the derived index: it promotes the fields needed for sorting, filtering, full-text search, and rollups. If a process stops after the transcript line is flushed but before the corresponding index transaction commits, the search index may temporarily miss the message, but the message itself remains readable. A later rewrite can rebuild the derived row.
The write order is therefore part of the reliability design. The transcript is written first, flushed, and then indexed. Normal rewrites use a sibling temporary file and an atomic rename rather than modifying a large live file in place. The design does not make every failure invisible. A crash during a streaming reply can still lose output that has not reached a checkpoint, and a tool that was still running may not leave a completed result. But the failure is constrained: committed user history is not treated as disposable because a secondary index or renderer update was interrupted.
PI-Desktop also checkpoints the assistant reply while it is streaming. The in-flight file is a transient companion to the durable transcript, replaced atomically as visible text arrives. When the final message is indexed, the transient checkpoint is removed. If the sidecar disappears before the final row lands, the host can promote the last saved reply as a completed or aborted assistant record according to the turn state. This is not an attempt to pretend the model finished successfully. It is a way to preserve the partial work and its status instead of allowing a process boundary to erase it.
The project and session relationship remains durable as well. A session keeps its project binding, model selection, operating state, and relevant permissions. That binding matters when multiple projects are retained in the sidebar. The user can look at repository B while a session for repository A is still running; the session's later events and tool roots remain attached to A. The foreground view changes, but it does not rewrite the meaning of work already in progress.
The work panel is different. Review artifacts, file resources, browser previews, and transcript-linked resources are retained in a session-scoped renderer context while the application is running. Switching away from a session does not destroy that context, so returning to the task does not make its review or preview disappear. Background work updates its originating context without opening or resizing the visible panel. A full relaunch intentionally discards the panel arrangement, however.