Sessions

A session is one conversation with the agent. Sessions are saved per project, under ~/.jan/projects/<slug>/threads, outside the repository.

Because they're per project, resuming from a different directory finds nothing - that's expected, not a bug.

Resuming

From inside the console:

For a headless run the value form needs an equals sign, because run takes a positional task that a space-separated id would swallow:

Starting fresh

Both drop the active goal along with the conversation.

Rewinding

Press Esc twice while idle to pick an earlier message and roll back to it.

In a git repository the agent snapshots your workspace as it works, so a rewind can restore the files too - not just the conversation. Outside a repository you get conversation-only rewind, which is the same behaviour minus the file restore.

This is the escape hatch when the agent goes down a wrong path: rather than arguing it back, rewind to before the turn that started it and rephrase.

Forking

A rewind is destructive: the turns after the point you roll back to are gone. Forking is the same cut without losing them - the prefix is copied into a new session and the original stays exactly as it was.

At startup, to branch instead of continuing:

The branch keeps the transcript, tool calls and diffs of the turns it inherited, and records the session it came from - which is what /tree draws. Sessions with no forks render as the flat list /resume shows.

This is what to reach for when a long session has built up context worth keeping and you want to try a second approach from the middle of it without destroying the first.

Working in a git worktree

By default the agent edits your checkout in place. With a worktree it gets its own, on its own branch, so a run you don't like costs a git branch -D instead of a revert:

Persistently:

A flag beats the project file, which beats the global setting, which beats the default - the same order as sandbox, and the reason --no-worktree exists.

The checkout lives under ~/.jan/worktrees/, outside your repository, on a jan/agent/<id> branch. /worktree in the console names the path, the branch, and what's changed there.

Getting the work back out is your own git - nothing here writes to the branch you left. A session remembers its worktree, so resuming returns to it; a fork gets one of its own, branched from where the source left off. A /fork taken mid-session is the exception: the checkout can't change under a running session, so the branch borrows it until you reopen the fork with --worktree, which is when it gets its own.

Nothing prunes these. When you're done with a session's work, the checkout and its branch go the usual way:

Delete the directory by hand instead and the next resume of that session quietly starts over from HEAD, saying so in the banner.

Queueing

Type while the agent is working and your message is queued instead of dropped. It's sent as soon as the current turn ends, and the footer shows how many are waiting:

Esc cancels the turn that's running, which is separate from the queue.

Inspecting from the shell

Threads are readable without opening the console. Output is JSON, so it pipes into jq:

What's stored

Under the project's store, ~/.jan/projects/<slug>/ (see Project Config):

None of it lives in your repository, so there is nothing to gitignore. The only file Jan keeps in the project is AGENTS.md (or a legacy JAN.md).