Jan Agent fork and rewind: history versus file restoration

Jan Agent fork preserves the original session while creating an alternative branch; rewind discards later turns. File restoration during rewind depends on a Git repository, and durable memory remains a separate store from conversation history.

The concrete application boundary

Current sessions are saved per project under ~/.jan/projects//threads, outside the repository. Resuming from a different directory can therefore show no sessions without indicating data loss. The session guide notes that terminal conversations share Jan Desktop’s thread store, while the memory guide separately distinguishes Desktop’s permanent agent-workspace memory from the terminal agent’s user and project memories. Do not collapse shared conversation visibility into automatic memory sharing. In a Git repository, the agent takes workspace snapshots so rewind can restore files; outside one, rewind is conversation-only. A fork copies the selected prefix into a new session and leaves the original transcript intact. It is not a promise of an independently isolated checkout (Jan Agent Sessions) (Jan Agent Memory).

A practical route

Start in the intended project directory and use /threads or /resume to locate the session. Use /fork to choose an earlier message and branch without destroying the original; /tree shows saved session relationships. For rewind, press Esc twice while idle and choose the earlier point. Before confirming a file-affecting rewind, inspect the current repository state and identify the snapshot boundary. If an independent checkout is required for the experiment, evaluate the documented worktree option separately rather than assuming a conversation fork creates one automatically.

A worked example

A long explanation led to an unwanted formatter edit, but its earlier reasoning is useful. Fork before the edit to try a narrower instruction while preserving the original discussion. Inspect the actual files in the active checkout before continuing. If instead rewinding the original, remember that later turns are removed and file restoration depends on the repository snapshot. A durable note learned during the task is another state to inspect separately.

Check	Record
Session	The selected project and saved thread identity.
History choice	A nondestructive fork or a destructive rewind of later turns.
File choice	The actual checkout and Git snapshot state, separate from session ancestry.

Reading the failure correctly

An empty session list from another directory can reflect project identity, whose store name includes path-derived identity. A successful fork does not validate tool permissions or reverse external effects. Generated memory indexes are also not ordinary transcript text; the documented memory store has its own files and update behavior (Jan Project Config) (Jan Tool Permissions).

What completes the check

The useful distinction is conversation branching, file restoration, and durable memory. Keeping those three states explicit lets an alternative local task preserve valuable context without pretending that one history action rewinds the whole environment.

Related background: llama.cpp server: a local API from a GGUF model, VRAM for LLMs: why model size is only part of the calculation.