Skip to content

Undo & branches

An agent that can edit files needs an undo that works. In the sandbox, every change the agent makes through its file editing is recorded with the version that was there before — so you can put it back.


Every file-change card in the conversation has Undo next to Open in Canvas. It asks once, naming the file and what putting it back would do, and then does it.

  • The card flips to a struck-through Undone, and a new card appears showing what you reversed.
  • Undo all in this run is on the group header and in the Changes panel — it reverses everything that run changed.
  • Your agent is told on its next turn that you undid something, and is instructed not to re-apply it unless you ask.

Two things are deliberately not undoable this way:

  • Changes made by a command. If the agent ran a script or a build that rewrote files, there is no per-file “before” to restore — the card says so and points you to restoring a checkpoint instead.
  • Anything while the agent is mid-run. Undo is disabled while the agent has the sandbox, because pulling a file out from under it produces a worse mess than waiting. Stop the run, or let it finish.

Undo files back to a point in the conversation

Section titled “Undo files back to a point in the conversation”

Hover any of your messages and you can undo files back to here — putting the files back the way they were when you sent it. The confirmation tells you exactly what that means: how many files, across how many runs.

If some of the changes in that window were made by a command and can’t be individually reversed, it says so and offers to restore a checkpoint instead, which resets the whole workspace to a known state.


An agent has one sandbox, and one run uses it at a time. When another conversation is holding it, the workspace says which one, by name:

Computer in use by “Fix the login bug” · expires in 4 m

You can keep typing and sending regardless; anything that needs the sandbox simply waits its turn, and the lock expires on its own. Undo, and restoring or deleting a checkpoint, are disabled while someone else holds it — each says which conversation has it, so you know who to ask or which run to stop.


For agents that work in a code repository, you can give each conversation its own branch. Then two people — or you, in two conversations — can have the same agent working on the same repository without stepping on each other.

When it’s on, the Git tab in the sandbox panel shows which branch this conversation is on, with two actions:

Apply to main workspace

Merges this conversation’s work back into the main workspace, and tells you how many files landed. If the same files changed in both places, it names them instead of forcing a merge.

Discard branch

Throws the branch away, after confirming that its changes are not merged. Useful when the experiment didn’t work out.

Helpers can work on their own branches too, so several helpers editing at once never overwrite each other. A helper working that way says which branch it used and what it left there.

Turn it on in the Console, under the agent’s Coding capability → Advanced, alongside the switches for helper delegation, branches, and the repository map.


Sandboxes can be restored from a snapshot after a long idle period or a restart. When that happens you get a card saying exactly what came back and what didn’t — for example:

Computer resumed from checkpoint · 2 files were not saved · 3 secret variables dropped · 1 background command stopped

That matters, because the things a snapshot deliberately leaves out are exactly the things you’d otherwise chase for twenty minutes: local environment files, secrets, and anything that was running at the time. Cards for commands that were running show stopped on resume rather than vanishing, and your agent is told the same thing, so it knows to restart the server rather than assuming it’s still up.