Session Branching
Session branching (forking) lets you create an independent copy of a conversation at any point. The new session diverges without affecting the original — useful for exploring alternative approaches, running “what if” scenarios, or preserving a checkpoint before a risky prompt.
/fork Command
The quickest way to fork — type in the chat input or on any channel:
/fork # fork with auto-generated label
/fork experiment-a # fork with a custom label
Available in the web UI, Telegram, Discord, Slack, Matrix, and all other channels. See Slash Commands for the full list.
Forking from the UI
There are three ways to fork a session:
/forkcommand — type/fork [label]in the chat input.- Chat header — click the Fork button in the header bar (next to Delete). This is visible for every session except cron sessions.
- Sidebar — hover over a session in the sidebar and click the fork icon that appears in the action buttons.
All three create a new session that copies all messages from the current one and immediately switch you to it.
Forked sessions appear indented under their parent in the sidebar, with a
branch icon to distinguish them from top-level sessions. The metadata line
shows fork@N where N is the message index at which the fork occurred.
Agent Tool
The agent can also fork programmatically using the branch_session tool:
{
"fork_point": 5,
"label": "explore-alternative"
}
label— label for the new session (required).fork_point— the message index to fork at (0-based). Messages at indices 0 through N-1 are copied; the message at index N becomes the first new message in the forked session. If omitted, all messages are copied.
The tool returns { "key": "<session-key>", "forkPoint": N }.
RPC Method
The sessions.fork RPC method is the underlying mechanism:
{ "key": "main", "forkPoint": 5, "label": "my-fork" }
On success the response payload contains { "sessionKey": "session:<uuid>", "forkPoint": N, "label": "..." }.
What Gets Inherited
When forking, the new session inherits:
| Inherited | Not inherited |
|---|---|
| Messages (up to fork point) | Worktree branch |
| Model selection | Sandbox settings |
| Project assignment | Channel binding |
| Agent ID | |
| MCP disabled flag | |
| Node assignment |
Parent-Child Relationships
Fork relationships are stored directly on the sessions table:
parent_session_key— the key of the session this was forked from.fork_point— the message index where the fork occurred.
These fields drive the tree rendering in the sidebar. Sessions with a parent appear indented under it; deeply nested forks indent further.
Deleting a parent session does not cascade to its children. Child sessions become top-level sessions — they keep their messages and history but lose their visual nesting in the sidebar.
Navigation After Delete
When you delete a forked session, the UI navigates back to its parent session.
If the deleted session had no parent (or the parent no longer exists), it falls
back to the next sibling or main.
Archive in the UI
The web UI also lets you archive sessions when you want to keep them without leaving them in the main sidebar list.
- Open More controls for a session and click Archive.
- Archived sessions are hidden from the default sidebar list.
- Enable Show archived sessions in the sidebar to reveal and restore them.
Archive is available for any non-main session, including cron and
channel-bound chats, except when the session is the current active session for
its bound channel chat. That prevents hiding the live Telegram, Discord, or
similar chat out from under the channel router.