Sessions
A session is an append-only log of events, which is what makes resume, fork, rewind and worktree isolation possible.
A session is one conversation with the agent in one workspace. Under the hood it is an append-only log of typed events. Everything Nib shows you, in any surface, is rendered from that log.
The event log
Each event has a sequence number (seq) that only goes up. A typical turn writes events like these:
| Event | Meaning |
|---|---|
user.message | Your prompt, including attached files and images |
assistant.start, assistant.delta, assistant.end | The model's reply as it streams, with reasoning and usage |
tool.start, tool.progress, tool.end | One tool call: its input, live output and result |
permission.request, permission.decision | A prompt for approval and how it was answered (by you, a rule, the mode, the classifier or a hook) |
question.ask, question.answer | The agent asked you a multiple-choice question |
todo.update | The task list changed |
checkpoint | Files were snapshotted before a mutating tool ran |
compaction | Context was summarized to free space |
session.status | idle, running, awaiting-input, error or archived |
subagent.update | Progress from a subagent |
error, notice | Something went wrong, or something you should know |
Because the log is the source of truth, a few things follow naturally:
- Reconnecting is cheap. A client that drops its connection resubscribes from the last
seqit saw and receives only what it missed. - Every surface sees the same thing. The CLI and the desktop app can watch the same session at once.
- History is inspectable. The REST API returns events by page, filtered by type.
Session identity
Every session has:
- An id, like
ses_01JC…, which is what you pass tonib --resume. - A title. Nib generates one from your first message with the small model; rename it with
/renameornib -n "title". - A short handle, like
api-tests, which other agents use to address it withSendMessage. - A model, an effort level and a permission mode, each of which you can change mid-session.
- An origin: started by you, by a subagent, by the CLI, by a schedule, or by a Nib Crew member.
Resume
Sessions persist across restarts. Pick up where you left off:
nib --continue # the most recent session in this folder
nib --resume # choose from a list
nib --resume ses_01JC… # a specific sessionInside the CLI, /resume opens the same list. /clear starts a new session; the old one stays resumable.
Fork
A fork copies a session's log into a new, independent session. Use it to try a different approach without losing the current one, or to branch off a long investigation.
nib --continue --fork-sessionIn the CLI, /fork [prompt] copies the current session in the background and leaves you where you are: /resume opens the copy, and a prompt gives the copy something to work on. /branch [name] makes the same copy and switches you into it. Forks can also start from an earlier point: the API takes a seq and copies only the events up to it.
Rewind
Rewind takes the conversation back to just before one of your earlier prompts, and by default restores your files to how they were at that moment.
- In the CLI, press Esc twice on an empty prompt, or run
/rewind, and pick the prompt to go back to. - The rewound prompt is put back in the composer so you can edit and resend it.
Rewinding truncates the log after that point. Sequence numbers are never reused, so clients can't confuse old and new events. Rewind is refused while a turn is running; interrupt first.
Checkpoints
Before any tool modifies files, Nib snapshots the files it is about to change into a content-addressed blob store. Rewinding to a point restores, for each path, the content it had at that point. A file that didn't exist then is removed.
Checkpoints cover changes made through Nib's file tools (Write, Edit, ApplyPatch, EditLines, NotebookEdit). Before a shell command that can change files, Nib also snapshots the session's working folder, so rewinding undoes what the command did there, a deleted directory included. They can't undo what a command does elsewhere, such as a database migration or a git push, or changes to files git ignores, to dependency and build folders (node_modules, dist, build, …) or to files over 5 MB. File tools don't snapshot files larger than 32 MB. Commit early if a change matters.
Worktrees
A session can run in its own git worktree, so its changes stay apart from your working copy and from other sessions. This is how you run several agents on the same repository at once without them stepping on each other.
- Worktrees live inside the repository by default (
<repo>/.nib/worktrees/<branch>, excluded from git);git.worktreeLocationmoves them. See Parallel agents. - The session's working directory mirrors your position in the repository. If you started in
packages/api, the session starts inpackages/apiinside the worktree. - When you delete the session, Nib can remove its worktree too.
Subagents can also request worktree isolation (isolation: worktree in their definition).
Interrupting
Press Esc in the CLI, or the stop button in the desktop app, to interrupt the running turn. The model stream is cancelled, running tools are stopped, and any partial assistant message is closed as aborted. The session returns to idle and you can continue.
A message you send while the agent is working reaches it at its next step, between tool calls. In the desktop app, ⌘↵ (Ctrl+Enter) queues it for after the turn instead; see Steering a running agent.
Compaction
Long sessions eventually fill the model's context window. Nib compacts in stages: it first trims large old tool outputs, then summarizes the conversation into a structured handoff that keeps the task list, files touched and decisions. The compaction event records what happened. You can compact by hand with /compact [instructions].
Export
/export [file] writes the conversation to a text file. Programs can read the raw event log through the daemon's REST API.
Where sessions are stored
The daemon keeps sessions in a SQLite database in its data directory, next to the checkpoint blobs and worktrees.
| Runtime | Data directory |
|---|---|
| CLI (default) | ~/.nib |
| Desktop app on macOS | ~/Library/Application Support/gg.nib.desktop/daemon |
| Override | --data-dir <dir> or NIB_DATA_DIR |
Cloud sync replicates the same event log across your devices. Each computer asks once, after you sign in, whether to sync its sessions, and you can change that under Account → Computers. See Your account and Your data.