Here is a thing that happens to everyone who works with a coding agent for long enough. Turn 12 was great. Turn 13 was a bold idea that did not work. Turn 14 was the agent trying to fix turn 13. By turn 16 you have a working directory you do not understand, a node_modules that was reinstalled twice, and a conversation so long the agent has forgotten what the original task was.
Git helps with the files, if the agent committed. It does not help with the installed packages, the database it seeded, the Firefox tab with the test page, or the agent's own memory of what it tried. You want to go back to the end of turn 12. All of it.
A snapshot of the machine, not the repository
Sessionboxer runs each session in its own Docker container. After every turn, if you leave the switch on, it takes a snapshot of that container: a docker commit. Files, packages, browser state, the agent's conversation files, everything in the box. The chat shows a small 📷 Snapshot #n marker with its size. The sidebar shows how much disk each session uses, snapshots included.
The default is to keep the last ten automatic snapshots per session. Manual ones, and any a fork was started from, are kept. Tokens are never written into a snapshot, so an image on disk is not a credential.
That is the boring part. The fun part is what you can start from a snapshot.
Fork: try two ideas at once
Click Fork from here on a snapshot marker and you get a new session with its own container, started from that image. Same files, same tools, same state. The original keeps running, untouched.
Three choices on the dialog decide what the fork knows.
Continue the conversation. The chat up to the snapshot is copied and the agent remembers everything. This is "go back to turn 12 and try a different turn 13". You can do it as many times as you like and compare the forks side by side. Delete the losers; the containers go with them.
Start a new conversation. Empty chat, same machine. Useful when the context has rotted: the files are good, the reasoning that produced them is 300,000 tokens of noise. A fresh agent on the same box is often sharper than the tired one.
Hand off. The origin agent writes a handoff document first (goal, state of the work, decisions made, open items, how to run and test, gotchas, no secret values), in a hidden turn. The fork starts a new conversation with that document as its first message. You can read exactly what the new agent was told.
Hand off to a different agent
The handoff is where it gets interesting, because the agent on the other side does not have to be the same one.
Each Sessionboxer Sandbox image carries one agent. When you fork into another agent, the new agent is copied into the fork's container from its own image before anything starts, and the chat notes Codex 1.1.9 added to this Sandbox. The snapshot's files are untouched; nothing inside it runs during the copy.
So you can:
- Have Claude Code explore a codebase and design a change, then hand the brief to Codex to implement it, because you have more Codex quota left this week. The usage bars tell you.
- Hand a half-finished task from the agent that has run out of ideas to a different model with a different training. A second opinion with the full state, not a copy-paste of the diff.
- Hand off from Claude Code to a fresh Claude Code. Same agent, new conversation, a brief instead of the whole history. This is the cheapest way to fix a rotten context.
The handoff needs the origin to be idle and running, because the origin is the one that writes the brief. If it cannot (limit hit, stopped in the meantime), the fork ends with an error that says why.
Start a new session from any snapshot
You do not have to fork from inside a session. The Environment picker on the New Session screen lists recent snapshots from all sessions. Pick one and the new box starts from that image with an empty conversation and your prompt.
This is how you avoid re-installing the world every morning. Set up a box once with the toolchain, the seeded database and the browser logged into the staging app. Snapshot it by hand. Every new task starts from there in seconds. Automations can start their sessions from a snapshot too, so a nightly job does not spend its first ten minutes on npm install.
Revert and branches, for the small cases
Not every mistake needs a new container. Each turn in the chat has a revert that rolls the conversation and the box back to that point, inside the same session. Revert twice and you have a branch tree in the sidebar: the turns you abandoned are kept, not deleted, so you can go look at what the agent did down the other path. The revert and branches chapter has the details.
Rule of thumb: revert when you want one timeline and a quick undo; fork when you want to keep both.
Why nobody else does this
The hosted agents (Devin, Cursor Cloud Agents, Codex cloud, Claude Code on the web) each run your task on a machine in their cloud, and none of them document snapshotting or forking that machine. It is a hard feature to offer at their scale, and there is no reason to let you fork into a competitor's agent.
On your own hardware it is just docker commit and a bit of bookkeeping. That is the general shape of the thing: features that are awkward for a hosted product are often easy for a box you own.
If you want to see it, start a session, let it do two turns, and click Fork… in the header. The snapshots and forks chapter in the guide has every option.