Fork a chat from any reply, then merge it back
Try another approach without losing the first: fork a Shuriken chat from any reply, keep the fork under its parent, then merge its work back in.
Contents
You know the moment. An agent has been going for twenty minutes, it's understood your codebase, and now you want to try something risky. Swap the state library, maybe, or rewrite the parser a different way. If it goes wrong, you'd like the chat you had five minutes ago back.
You can do this in Claude Code's terminal: resume the session with --fork-session and you get a new session id instead of reusing the original (Claude Code CLI reference). It works. But you're left with two session ids, both editing the same folder unless you set up a second checkout yourself, and nothing that brings the good result back into the original.
So in Shuriken 5.1 forking is a button, the fork lives under its parent, and when the experiment works, Merge into … brings it home.
Fork from any reply#
Under every finished answer from the agent there's a fork button. Your own messages don't have one: a fork always starts after one of the agent's replies. Pick Fork chat from here, then one of two places for it:
- Fork in a new tab: a second conversation beside the first, in the same chat. Good for a quick "what if" that doesn't need its own branch.
- Fork as a new chat: a full chat of its own, with its own branch and worktree like every other chat in Shuriken, so its changes can't touch the original's files.
Either way the fork starts with the conversation up to that reply, and nothing after it. The agent remembers the codebase tour it already did. The bad turn you're trying to avoid never happened, as far as the fork is concerned.
Forks sit under the chat they came from#
A fork made as a new chat isn't dumped at the top of your list as "New session 14". It sits under the chat it came from in the Chats list, with a thin line joining them, on every device you use. Fork the fork, and it nests one level deeper.
That sounds like a small thing. It's the difference between "which of these nine chats was the experiment?" and seeing it at a glance.
Merge into …: bringing the work back#
When the fork's way turns out better, choose Merge into followed by the parent's name from the fork's ⋯ menu. On the desktop you can also double-click the fork's row, which asks first. Then Shuriken:
- commits what the fork left uncommitted, under a fixed message;
- merges the fork's branch into the parent's branch, in the parent's own checkout;
- adds a short note to the parent chat saying what the fork did, built from the fork's last answer.
That note matters more than it sounds. The same summary goes in front of the parent's next prompt, so the parent's agent knows that its code just changed and why. No more "wait, who rewrote this file?" from your own agent.
Writing the summary costs you nothing, by the way. It's taken from the fork's own last answer, with no extra model call.
Two safety rails:
- If the parent has uncommitted changes in the same files, Shuriken stops and asks you to commit them first. Nothing gets silently overwritten.
- The fork stays after merging. Removing it is its own action (Archive), as for any chat, so you can still read how it got there.
When to fork, and when to start fresh#
Fork when the context is the valuable part:
- Trying two approaches. Fork at the point where the paths split, run both, merge the winner.
- A risky refactor. Fork before it starts. If it goes sideways, the original chat never saw it.
- A side quest. The agent spotted a bug you don't want to deal with now. Fork, let the fork fix it, merge it in later.
Start a new chat when the context would only get in the way: a different feature, a different part of the codebase, or a conversation that's long enough to slow things down. For quick questions that don't belong to any project at all, 5.1 also adds chats without a project.
And when a whole chat's work is done, forks merged in or not, Finish runs your checks and merges the branch into your default branch in one click.
Works with everything else#
Forks are ordinary chats. They use your sources and switching like any other chat, they run in parallel with everything else (here's how we run many at once), and their files show up as file cards.
Forks and Merge into are part of Shuriken 5.1, on every plan. Try Shuriken and fork your next chat.
Sources
- Claude Code CLI reference (accessed 22 October 2026)
Frequently asked questions
How do I fork a Claude Code conversation in the terminal?
Resume it with the --fork-session flag, for example claude --resume <session> --fork-session. Claude Code starts a new session id instead of reusing the original, so the old conversation stays as it was.
Where do forks show up in Shuriken?
In the Chats list, nested under the chat they came from, on every device. A fork of a fork nests one level deeper.
What does Merge into do with uncommitted work?
It commits what the fork left uncommitted under a fixed message, merges the fork's branch into the parent's, and adds a short summary of the fork to the parent chat. The fork itself stays until you archive it.
What if the parent chat has uncommitted changes in the same files?
Shuriken stops before merging and asks you to commit them first, so nothing gets overwritten.