Sessions & state
A Roder session is a thread of turns, messages, tool calls, policy events, and workspace state. Session behavior is defined in roder-api and implemented by installable session-store extensions.
Storage
The default distribution installs roder-ext-jsonl-session. It persists transcripts and snapshots in a JSONL-friendly shape so sessions can be resumed, inspected, and replayed without a database.
Snapshots
App-server clients can create, list, load, and inspect sessions through typed protocol responses such as SessionMetadata and ThreadSnapshot. Extension-owned state can also be persisted through the session-store contract.
Compaction boundaries
Session history remains durable even when the active model context is compacted. Roder treats local ContextCompaction records and OpenAI Responses provider compaction metadata as hard boundaries for future inference requests. New turns keep the compact state plus later work, while older chat and tool output stay available for inspection and replay instead of being re-sent to the provider.
Resume flow
- The client requests a session list or supplies a thread id.
- The app server asks the runtime store for the matching snapshot.
- The TUI or desktop client rehydrates transcript, mode, pending approvals, and visible state.
- New turns continue against the same canonical thread id.