Sessions

Zagens organizes work into sessions (conversations) scoped to a workspace.

Session sidebar

• New session — fresh thread in the current workspace
• Session list — resume past chats for this folder
• Show all sessions — optional toggle to include history from other workspaces

Each session remembers messages, tool calls, and thread state in local SQLite storage (via the runtime sidecar on desktop, or in-process in TUI/CLI).

Restore after restart

When you reopen Zagens, the chat shows restore progress and the data source (cache / thread replay / session archive). Since v0.8.0, Kernel V3 prefers log-first transcript repair from the kernel event log when session JSON alone is incomplete — see Kernel V3. Incomplete history shows a degraded warning; use Reload to retry thread event replay. Tool call cards restore from persisted threads (not localStorage alone).

Parallel multi-session streaming

Since v0.8.3 / 0.8.4, switching sessions lets background turns keep streaming (session strip shows in-progress). Each session can have its own config overlay (LHT, approval, …) without restarting the sidecar. See Streaming.

Task type and sessions

When you switch Code ↔ Office task type, Zagens starts a new session so tool surfaces and model KV stay consistent. Plan separate sessions for engineering vs document work.

Workspace binding & isolation

Sessions belong to the active workspace path. Changing workspace switches which session list you see.

Composer ⋯ → Session isolation can create a git worktree under .worktrees/ for parallel edits on the same repo.

Checkpoints

On user messages: Restore files (pre-turn snapshot; chat unchanged) vs Branch (fork the thread). See Snapshots.

Tips

• Name goals clearly in the first message — it helps long threads stay on track.
• Delete obsolete sessions from the sidebar menu when tidying up.
• For support, export JSON or a Kernel Trace Report before deleting (see Replay & export).

Related: Streaming · Context usage