Exploring chat forking | Ness
Announcements
Announcement · August 19, 2026
Exploring chat forking
One of the big reasons I built Ness is that building my own<br>development environment allows me to explore deeper into what<br>agentic development could actually be like. Recently I have been<br>exploring the concept of “chat forking” which<br>basically means starting a 2nd conversation that has all of the<br>history of the first one.
original
fork
The conversation so far
you: here's the schema, let's plan the migration
read 14 files · ran the tests
you: no, don't add a new table
agent: ok — backfilling in place
fork<br>A 2nd conversation, starting from all of that
↳ everything from the original, verbatim
you: unrelated — can we drop the cron?
The original, untouched
Still on the migration, with none of the tangent in its context.
A fork copies the transcript up to a point and resumes it as a<br>new session. Nothing is taken away from the chat you forked.
I have found this extremely useful in a few cases, and I<br>wanted to share those here. My request for you dear reader is<br>that if you find these useful or most importantly you have<br>other ideas on what we could do with this feature: please<br>share.
Forking when I get distracted
The place where I started (so maybe the most obvious place? I<br>guess at least it was the most obvious to me) was times when I<br>wanted to ask the agent about something tangentially related<br>to the work we are doing, but didn’t really want to burn<br>context window on my random side idea.
This is especially useful when you know the agent has already<br>deeply researched some element of your codebase or some<br>framework, and you are interested in how you might be able to<br>use the new software in the future.
main chat
fork
Implementing some big feature branch
The agent has already read half the codebase to get here.
fork
“actually i was wondering, would this allow us to xyz”
Asked against all of that research, on someone else’s context window.
Main chat keeps implementing
And doesn’t lose focus.
I’ve used this probably 20 times in the last week. Most<br>of the examples are a bit too specific to my world but<br>I’ll try to pull something specifically from Ness<br>development:
The existence of the separate command line tool<br>lochy came<br>literally from a forked chat. I was talking to the agent about<br>building a feature that basically “Sends Worktree to a<br>remote machine” which will copy all of your work &<br>Claude Code chats related to the work to a remote computer. As<br>part of that discussion I realized we don’t really have<br>a standardized way of manipulating JSONL chat logs (the data<br>layer behind most of the code harnesses today). The prototype<br>lochy was started in the fork of the chat I made when I<br>realized the work we had to build to transfer chats to a<br>remote machine should be baked into its own CLI utility,<br>rather than being baked into the node monstrosity that is<br>Ness’ server runtime.
Forking chats to make worktrees
The other hugely useful situation I figured out for forking<br>was “Forking chats to start new worktrees”. This<br>is best explained by talking through how things worked before,<br>and how forking is so much better.
Ness is built around the idea that every change to your<br>codebase should happen in its own worktree.
For the uninitiated, a worktree is basically a git branch, but it’s in its own folder
So instead of git checkout which<br>changes your current folder to track a target branch, a<br>worktree would make a new folder, and then target the<br>branch, allowing you to work on the code and keep your other<br>work around.
A very common use-pattern in Ness is to have agent chats in<br>your main (the artist previously known as master) branch where<br>you discuss issues you are seeing, the agent will research the<br>issue for you, and then spin up a worktree on your behalf.<br>(This is one of the awesome things that the Ness MCP server<br>gives you, the agent itself can spin up a new worktree right<br>in Ness). This is very useful because the agent can turn<br>something like “hey for some reason this page won’t<br>load when I am logged in as mike” into a fully<br>researched ticket, and spin up a worktree immediately.
This, however, breaks down when the conversation to figure out<br>a bug or to scope out a new feature grows far longer than a<br>message or two. In the same pattern I will find myself<br>speccing out entire PRDs or running a bunch of devops queries<br>against Datadog or the database, collecting a ton of context<br>that is useful to a bug. When it finally comes time to spin up<br>the worktree (or worktrees) the agent does its best to write a<br>prompt, but will often fail to collect all of the information<br>necessary.
That’s where forking comes in. In the 2.14 launch of<br>Ness we added the ability for the create_worktree<br>command to bring with it a conversation fork. Now instead of<br>starting a worktree from a single prompt,...