A coding agent session today is one long thread, and everything you ask stays in it. A quick side question about a library, a half-finished experiment or a wrong guess all sit in the context and shape later answers. We think sessions will work more like version control: you branch to ask or try something, the main line stays clean, and only a summary you chose comes back. Claude Code and Codex can already fork a session natively. Synapse has forks with a visible tree, new in its Mac app for Claude Code and Codex. Diffing sessions, rebasing context and sharing a fork with a teammate are what we expect next.
One thread, everything in it
Picture a normal afternoon. You have spent an hour with Claude Code on a payment retry feature. The agent knows the schema, the queue, the three places retries are triggered, and the decision you made to keep idempotency keys in Postgres. The session is in good shape.
Then you wonder whether the HTTP client supports per-request timeouts. You ask. The agent reads the client's source, quotes two files, tries a snippet that fails, and explains a workaround. Useful, and done in five minutes.
But that exchange is now part of the session. The source it read, the failed snippet and the workaround all sit in context next to the retry design. Twenty minutes later the agent suggests using that workaround inside the retry loop, where it does not belong. Or the session gets compacted, and the summary spends some of its space on the timeout detour and less on the idempotency decision.
This is the basic shape of the problem. A session is a single thread. Every question, right or wrong, relevant or not, becomes part of what the agent remembers. The longer and more valuable a session gets, the more expensive a side question becomes, because it is mixed into the context you worked hardest to build.
People already work around this by hand. They open a second terminal for the side question and copy the important part back. They start a fresh session and paste in a summary. They avoid asking at all. Each of these works, and each one loses something: either the side session starts with no context, or the main session gets polluted anyway.
Why version control is the right model
Source code had the same problem long before agents. If every experiment went straight onto the main line, the main line would be a mess. Branches fixed that. You branch, try something, and either merge it on purpose or throw it away. The main line only changes when you decide it should.
An agent's context is closer to source code than to a chat log. It is state that a later step depends on. So the same ideas apply:
| Version control | Agent session |
|---|---|
| Branch | Fork the session to ask or try something |
| Main line | The session doing the real work |
| Commit | A turn in the conversation |
| Merge | Bring a result back into the parent on purpose |
| Discard a branch | Close the fork, nothing leaks back |
| Log and lineage | Which session forked from which, and when |
The important part is the default. In a thread, everything flows into the main context unless you take it out. In a branch model, nothing flows back unless you put it in. That flip is the whole point.
What "merge" should mean for context
Merging code is mechanical: lines change, and conflicts show up as overlapping edits. Merging context is not. You almost never want the fork's full transcript in the parent. That would bring back exactly the noise you forked to avoid.
What you usually want is one of these:
- Nothing. The side question was for you, not for the agent. You read the answer and close the fork.
- A short summary. "The HTTP client supports per-request timeouts via
opts.timeout. Do not use the global setting." Two lines, written by the fork, sent to the parent. - A decision. The fork tried two designs and one failed. The parent needs the conclusion and the reason, not the attempt.
- A pointer. The fork found something that matters later. The parent gets a note that it exists and where to look.
So merge for context is a write, not a copy. Someone, either you or the forked agent, has to decide what is worth bringing back and phrase it so it does not mislead the parent. That is extra work, but it is also the moment where quality is decided. A summary written on purpose is easier for the parent to use than a transcript it has to sift through.
There is also a question of trust. A fork may have been wrong. If its summary goes into the parent as fact, the error spreads. Our view is that merged summaries should be labelled as coming from a fork, the same way you would treat a note from a colleague: useful, worth checking.
What exists today
The building blocks are already here. Claude Code can fork a session with claude --resume <id> --fork-session, which starts a new session from the same history without changing the original. Codex has codex fork <id>. Other tools, including Superset, have shipped forking on top of these commands.
What is mostly missing is the shape around them. Forking from the command line gives you a new session, but it is up to you to remember which session came from which, and to carry anything back.
How forks work in Synapse
Synapse is what we build, so read this section with that in mind. Forks are new in the Synapse Mac app. They are not in the open-source main release yet, and today they work with Claude Code and Codex only.
The interaction is meant to be quick enough that you use it for small questions:
- Inside the agent, type
/sfork <question>, or press ⇧⌘F. - Synapse forks the session with the agent's own native command and opens the fork as a card stacked on top of its parent.
- The fork answers the question. The parent never sees it.
Hover the stack to see the tree of forks. ⌘E opens a full fan view of every fork in that session. On the canvas, lineage shows as a dashed line with ⑂ from child to parent, so you can see at a glance which sessions are side branches of which.
The return path is opt-in. A fork sends nothing back by default. If you want the result in the parent, you ask the fork to send a short summary with synapse send, and it arrives in the parent as a message from a peer, not as a user instruction. That is the "merge is a write" idea in practice: the parent only gets what someone chose to send.
This is early. There is no session diff, no rebase, and forks cannot be shared with another person yet.
What we expect next
The following is speculation. It is where we think this goes, and what we would like to build or see built.
Session diffing. Within a few years we expect to compare two sessions the way you compare two branches. You fork a session, try a different approach in each, and ask: what does the fork know that the parent does not? Which files did it read, which decisions did it make, where do they disagree? A diff of context is less precise than a diff of code, but even a list of "files read", "commands run" and "claims made" per side would be useful.
Rebasing context. Long sessions drift. The early part of a session often contains wrong guesses that were later corrected. Today the only fix is compaction or starting over. Our bet is that you will be able to rebase a session: replay the important turns onto a clean start, drop the dead ends, and keep the decisions. Think of squashing the experimental commits before merging, applied to an agent's memory.
Sharing a fork with a teammate. Today a session is private to one person on one machine. A natural next step is to hand someone a fork: "here is my session as of the retry design, ask it what you need". They get the context without your later detours, and nothing they ask flows back into your main line unless you merge it. This needs care. A fork carries everything the session saw, and sharing it means deciding what the other person is allowed to read.
Trees as the default view. Once forks are cheap, a single session becomes a small tree: a main line with short branches for questions, experiments and reviews. We expect tools to show that tree the way git tools show a commit graph, and for "where did this agent learn that?" to have an answer you can click through.
None of this needs the models to change. It is mostly bookkeeping around commands that already exist. That is why we think it will arrive soon.
FAQ
Why not just start a new session for a side question?
A new session starts with no context, so you spend time re-explaining the project before you can ask the question. A fork starts with the full history of the parent, answers the question with that context, and leaves the parent untouched. It is the difference between asking a new colleague and asking the same one in a separate room.
Can I fork a Claude Code or Codex session without Synapse?
Yes. Claude Code supports claude --resume <id> --fork-session and Codex supports codex fork <id>. Synapse uses the same commands and adds the stacked cards, the visible tree, lineage on the canvas and the opt-in summary back to the parent.
Does a fork's answer ever reach the parent session automatically?
Not in Synapse. Nothing returns by default. If you want the result in the parent, the fork sends a short summary with synapse send, and the parent sees it as a message from a peer agent.
Which agents does Synapse support for forks?
Claude Code and Codex, in the Synapse Mac app. Forks are not in the open-source main release yet.