Pi /fork or /clone: a separate session
The shared session A new starting point
You chose the inline alternative. Decide whether to keep its answer or revise the question that led to it.
The inline answer is useful. I want to continue from it, but keep the new work in its own session.
Use /clone for a separate copy of the active path. In this example, the copy includes the shared opening and the completed inline exchange. The sibling modal exchange remains in the original session.
What this clone carries forward
- Your original request for a wait-list form.
- The reply proposing confirmation beside Submit.
- Your request for inline feedback readable without colour.
- The reply describing a polite status region and keeping focus on Submit.
Your next message can ask about that completed answer: “Add a request number without moving focus.” This inventory describes a four-message teaching example, not every entry a real session may contain.
I actually want to rewrite “Keep it inline…” before getting that answer. Would cloning do that?
No. Use /fork and select that earlier user message. The separate session starts before the selected prompt; its text returns to the editor. The inline answer is not part of that starting history.
Read the two starting points
- Clone after the inline answer
- History: messages 1, 2, 5 and 6. Editor: empty. Your next message follows the answer you chose to keep.
- Fork at the inline question
- History: messages 1 and 2. Editor: “Keep it inline and make the confirmation readable without colour.” Revise this before submitting; the old answer is not carried as a reply to the revision.
- Tree at that same question
- The same earlier conversation point and restored text, but in the existing session file. Use this when the alternatives belong together.
A separate conversation needs a recognizable name
Before branching, use /session to check which session is active. After the new session is created, check it again and use /name to give it an intention such as “inline receipt wording.” A name helps you find the work later; it does not identify a Git branch or deployment.
When resuming later, use pi --resume or interactive /resume to choose a session. pi --continue follows the latest session for the current directory, which may be your experimental copy. Read the opening and latest messages rather than assuming that “most recent” means “approved.”
Keep the distinction visible in your own notes: “Session A explores the modal; Session B explores inline confirmation.” Neither sentence proves that either interface has been implemented.
Can I now run both sessions against the same project?
The new session is a separate conversation file, not an isolated working directory. Two sessions can still edit the same files. Review the current changes and choose an explicit isolation plan before doing concurrent edits.
When the original session must remain useful
A clone is useful for taking the current direction elsewhere. A fork is useful for changing an earlier question. Neither is a replacement for keeping a recoverable copy of work you care about. In a real session, saved entries can include tool output and file contents beyond the text visible in this example.
If you share a transcript to explain a branch decision, inspect it first. The /export and /share paths are separate actions; a local teaching download from this site does neither. Use the source packet below when you want an example that contains only the fictional wait-list conversation.
Sources and limits of this comparison
The command distinction and resume controls follow the pinned session guide. The AgentSession implementation supplies the fork/clone behavior. Installed extensions can participate in lifecycle behavior; inspect your configuration when it differs.
Download the reproducible conversation example. Its checks exercise context projection. They do not launch Pi or verify full fork/clone file writes, provider behavior or your installed extensions.