forklisted

Fork a session: $ARGUMENTS Branch a conversation into a NEW, independent session so you can explore an alternative direction without touching the original. Where `/continue` resumes the *same* thread, `/sessions:fork` launches a new same-harness sibling — the "git branch" of conversations. Typically called as bare `/sessions:fork` (fork the CURRENT session) or `/sessions:fork <id>` (fork a specific one). The fork is **not** a transcript copy: `agents sessions fork` resolves the source across the fleet, builds a **recap** of it (label, cwd, ticket, last state, changed files, and the source id), and launches a same-harness sibling seeded with that recap. That is what makes it work for a session on **any device** and in **any REPL harness** — the sibling is handed plain text, so it never has to reach a transcript that may live on another box. It costs the recap's tokens, not a full re-run, and the sibling can pull full history with `/continue <source-id>` if it needs more. ## Step 0: Resolve which session to fork - **Bare `/sessions:fork`** — fork THIS session. Its id is in the session-start context ("Your current session id is …"); use that. - **`/sessions:fork <id>`** — fork that session (UUID or short prefix). The lookup is cross-fleet, so a remote id resolves. Never guess an id — if `$ARGUMENTS` is a topic/name rather than an id, run `agents sessions "<query>"` to resolve it first, or ask once. ## Step 1: Fork it where the user works One command launches the sibli