| Fork a session | In the TUI, type /fork (or /fork <name> to name the copy) to copy the current chat into a new chat with a fresh ID; the original is left untouched. From the shell, codex fork opens a session picker, codex fork --last forks the most recent session, and codex fork <id-or-name> forks a specific one. /side (alias /btw) opens a throwaway side chat forked from the current one. codex fork --help says SESSION_ID must be a UUID, but 0.162.1 also accepts a session name, like codex resume.
Source | Inside a session, /branch [name] copies the conversation and switches you into the copy, while /fork [prompt] copies it into a new background session (its own row in claude agents) and keeps you where you are. From the shell, add --fork-session to claude --continue or claude --resume <id|name> to continue in a copy with a new session ID. /fork became a background copy in v2.1.212; before that (and whenever agent view is turned off) it starts a forked subagent, which is now /subtask.
/fork was the old name of /branch before v2.1.77.
A session started with flags the copy can't inherit, such as a replaced system prompt or a --tools allowlist, can't be copied with /fork. Source | Type /fork (aliases /branch and /duplicate) in an interactive session. It copies the current chat into a new session, switches you into the copy, and prints agent --resume <id> so you can get back to the original. There is no --fork flag or agent fork subcommand. /fork is refused while the agent is still working or before the chat has any messages.
Source | Yes. In the TUI run /fork (or bind session.fork) and pick "Full session" or a prompt; from the command line use opencode run --fork or opencode mini --fork together with --continue or --session <id>. In 2.0.28 the full-screen opencode command has no --fork flag (1.x had one); use /fork after opening the session, or opencode mini --fork. Source | Yes, three ways. /clone copies the current branch into a new session, /fork makes a new session starting just before an earlier user message you pick, and /tree branches inside the same session file. From the shell, pi --fork <path|id> copies an existing session into a new session for the current folder before interactive mode starts. /fork and /tree have keybinding actions (app.session.fork, app.session.tree) that are unbound by default. Pressing Escape twice on an empty editor opens /tree by default; set doubleEscapeAction to "fork" or "none" to change that.
Source |
|---|
| Fork or rewind from an earlier point | Partly You can't fork from an earlier turn in the CLI: /fork, codex fork and codex exec fork always copy the whole conversation. You can rewind the current chat instead: press Esc twice with an empty composer, pick an earlier prompt with Left/Right, and press Enter. Codex drops that prompt and everything after it from the saved history and puts the prompt back in the composer to edit. The docs say Esc-Esc forks the chat from that point. Since 0.156.0 it rewinds the same chat in place, so the later turns are gone from that chat. To keep them, /fork first. Rewinding only works on sessions in the newer paginated history format. Older sessions can be converted with codex migrate-rollouts --apply. The app-server thread/fork request can fork at a turn (lastTurnId, or experimental beforeTurnId), but the CLI doesn't expose this. Source | Partly In the terminal, /rewind (aliases /checkpoint, /undo) or Esc twice on an empty prompt opens a list of your earlier prompts, where Restore conversation rewinds the current session to that point rather than making a copy. The VS Code extension has Fork conversation from here on any message, and the Agent SDK's forkSession(sessionId, { upToMessageId }) copies the transcript only up to a chosen message. /branch and --fork-session always copy the whole conversation as it stands; to branch from an earlier point in the CLI, run /branch first and then /rewind in the copy.
Source | Partly /fork always copies the whole chat; the CLI has no fork-from-message option. /rewind (aliases /undo, /restore) opens a turn timeline and moves the current chat back to an earlier message, either restoring files and conversation or the conversation only. To branch from an earlier point, run /fork and then /rewind inside the copy.
/rewind is on by default since v2026.06.22 and can be turned off with the rewind key in cli-config.json or in /config.
The Cursor editor can fork from a specific message, copying the chat through that message and dropping later ones. Source | Yes. /fork lists earlier prompts, and choosing one copies the history before that prompt into a new session and pre-fills the prompt; a message's action menu also has Fork. To rewind in place, /undo (<leader>u) or a message's Revert stages a rollback that becomes final when you submit, and /redo (<leader>r) cancels it. Source | Yes. /fork lists your earlier user messages and starts a new session just before the one you pick, putting its text back in the editor so you can edit and resend it. /tree lets you jump to any earlier entry in the same session; picking a user message refills the editor, and the branch you leave stays saved. When you leave a branch, Pi can ask whether to summarize it into the branch you move to. Set branchSummary.skipPrompt to true to skip the summary question and never summarize. Source |
|---|
| What the fork keeps | A fork copies the full conversation and keeps the current model, reasoning effort, permissions profile, working directory and any active goal. It doesn't keep the session name. You can rename it with /fork <name> or /rename. codex fork accepts the usual overrides, such as -m, -s, -a, -c key=value, -C <dir>, --add-dir and -p, to change these for the new chat. A /side chat inherits history only as reference. It is told not to make edits or use subagents, and it can't be renamed. Source | Every fork copies the conversation history up to the fork point. /branch stays in the same process, so model, settings, "allow for this session" grants and running background work carry over; /fork copies the model, permission mode, effort and any added directories and "don't ask again" grants into the new background session. A --fork-session launch is a fresh process: session-only grants are not carried, launch flags like --model or --permission-mode apply to the copy, and it starts in the directory you launched from. With --fork-session, a session that ended in plan mode is not put back into plan mode. Source | The fork gets the full conversation history, including subagent and summary data. In CLI 2026.10.12 it also keeps the mode (agent, plan or ask), the last-used model, the Run Everything and approval settings, and the current plan file. It runs in the same working directory, and you can change model or mode afterwards with /model or Shift+Tab. Flags such as --model or --force can't be passed to /fork itself. Source | The fork copies finished history (assistant turns still running are skipped), the session's agent, model, permission rules, metadata, and current instruction state, and opens in the original session's directory and workspace. It gets the title <original> (fork #1) and starts with zero cost and token counts. Source | /fork and /clone copy only the active branch up to the chosen point (with its labels, compactions and any model or thinking-level changes) into a new file in the same session folder, and keep the session's working directory. Pi then reloads the session, so the model and thinking level come back from the copied history, and --model or --thinking flags you started Pi with apply again. pi --fork copies every entry, including other branches, and moves the copy into the current folder. Pi has no permission prompts to carry over.
Source |
|---|
| File changes and worktrees | Partly Forks don't snapshot or rewind files. By default a fork shares the same working directory. In a Git repo, /fork asks Where should the forked conversation run?, and you can pick Create new Git worktree. codex fork <id> --worktree and codex exec fork <id> --worktree do the same thing. Esc-Esc rewinds only the conversation and never your files. The managed worktree is a detached checkout of the current HEAD commit, so uncommitted changes are not copied into it. --worktree needs an explicit session ID and local execution. It can't be combined with --last, the picker, --ephemeral or resume.
Source | Forking copies the conversation, not your files: /branch and --fork-session keep working on the same checkout. /fork copies are told to make their code changes in a git worktree of their own, and you can start any session isolated with claude --worktree <name>. Separately, checkpoints let /rewind restore files that Claude's edit tools changed (Restore code, or Restore code and conversation). Checkpoints don't cover changes made by Bash commands, most subagent edits, or symlinked and hard-linked files. A fork made with the SDK's forkSession() doesn't include the original's file checkpoints. Source | Partly Forking does not copy or isolate files: the original and the fork edit the same working tree. /rewind can undo file changes, offering Restore files and conversation or Restore conversation for a chosen turn. For separate files, start a session with -w/--worktree [name], which runs it in its own git worktree under ~/.cursor/worktrees/<repo>/<name>. Rewinding files in a fork also changes them for the original chat, because both share the same directory. Rewind file history is stored locally and isn't a replacement for git. Source | Partly No. The fork shares the same working directory. Files are rewound only by /undo and Revert, which restore paths from OpenCode's snapshot store (needs a Git repository; turn off with "snapshots": false). For isolation, ask the agent to call worktree_create and session_move, or use /worktrees to move the session to another workspace. Source | Not supported No. Forking, cloning and moving around /tree only change the conversation; files on disk stay as they are, and Pi has no checkpoints or worktrees. The repository ships an example extension, examples/extensions/git-checkpoint.ts, that saves a git stash create snapshot each turn and offers to apply it when you /fork. Source |
|---|
| Where a fork came from | Partly When a fork opens, Codex prints Thread forked from <parent name> (<id>), and /status shows a Forked from line. To switch between the parent and the fork, use /resume, codex resume <id-or-name>, or the codex agents command center. There is no branch tree view. Source | Partly /branch prints both the new and the original session IDs, and the original stays in the /resume picker, so you switch back with /resume <original-name> or its ID. /fork copies show up as their own rows in claude agents and /resume with a ⑂ fork name, and SDK forks are titled after the original with (fork). There is no tree view of parent and child sessions.
SessionStart hooks see source: "fork" when a session starts as a fork. Source | Partly The fork is named after the original with (forked) appended, and /fork prints the original chat's ID. Both chats appear as separate entries in agent ls / /resume. In CLI 2026.10.12 no parent link is stored, so there is no branch tree or switcher; you switch with /resume or agent --resume <chatId>. Source | Partly Each fork records its source session and boundary in the fork field (sessionID, boundary) returned by the session API, but the TUI does not show it. Forks are top-level sessions, so you switch between them with /sessions (<leader>l). Source | A session made by /fork, /clone or --fork stores the source file path in parentSession on its first line. The /resume picker's Threaded sort (switch sorts with Ctrl+S) nests forks under the session they came from. Inside one session, /tree shows every branch, and you can label entries with Shift+L and filter the view. Source |
|---|
| Fork from the SDK or API | In headless mode, codex exec fork <id-or-name> [PROMPT] copies a saved session. Add --json for JSONL events, --ephemeral to keep the fork unsaved (this needs a prompt), or --worktree. With no prompt, the fork is created without starting a turn. The app-server thread/fork request and the Python SDK codex.thread_fork(thread_id, ephemeral=..., model=..., sandbox=...) also fork. thread/fork adds lastTurnId/beforeTurnId to fork from an earlier turn. Source | Headless: claude -p --resume <id> --fork-session "prompt". In the Agent SDK, set forkSession: true (fork_session=True in Python) together with resume, or call forkSession(sessionId, { upToMessageId, title }) / fork_session() to copy a transcript without running it; resumeSessionAt resumes at a specific message. For an unsaved fork, combine it with --no-session-persistence (print mode) or persistSession: false in the SDK. Source | Not supported No. Headless mode (agent -p) can continue a chat with --resume <chatId>, but it has no fork option. The ACP server (agent acp) supports session/new, session/load and session listing, but not forking. agent create-chat makes a new empty chat and returns its ID. It does not copy an existing one.
Source | Yes. POST /api/session/{sessionID}/fork takes an optional before message ID (omit it to copy everything). opencode run --continue --fork and opencode run --session <id> --fork fork headlessly, and opencode acp advertises and handles ACP session/fork. To change the model or agent, pass --model or --agent to the opencode run --fork call that sends the next prompt; the fork endpoint itself accepts no overrides. Source | Yes. In the SDK, AgentSessionRuntime.fork(entryId, { position: "before" | "at" }) forks or clones, SessionManager.forkFrom() copies a whole session file, and SessionManager.branch() and createBranchedSession() work on the tree directly. RPC mode has fork, clone, get_fork_messages and get_tree commands, and pi --fork <id> -p "..." forks for a one-off headless run. Extensions can cancel or react to a fork through the session_before_fork event, and fork themselves with ctx.fork(entryId, { position }). Source |
|---|