Undo an agent's file changes without losing your own

• Checkpoint records a recoverable state.
• Rewind returns to a specific message.
• Worktree isolates parallel changes.

All three touch file state, but none of them replace your own Git commits and branch management.

flowchart LR
  Change["File change"] --> Checkpoint["Checkpoint"]
  Checkpoint --> Continue["Continue executing"]
  Continue -->|"return to a message"| Rewind["Rewind"]
  Continue -->|"isolate parallel work"| Worktree["Worktree"]
  Rewind --> Restore["Restore files and conversation view"]
  Worktree --> Integrate["Review, then merge"]

• Workspace & Session
• Reference: storage

Checkpoint: link file state to a Session message#

Checkpoint records your Workspace's state as the agent works, and attaches each recovery point to a specific Session message.

How it's stored#

Checkpoint uses an independent shadow Git repository. It never creates commits inside your Workspace's own .git, and it never pushes recovery history to your remote.

What it captures#

A recovery point lets you restore the file state touched by an agent's edit. The Session timeline keeps the relationship between a message and its Checkpoint, so you can trigger Rewind from a specific turn.

Where you see it#

A recoverable message shows a Rewind entry point in the timeline. Session Changes and the Diff view show you what changed right now — a Checkpoint existing doesn't mean you've already accepted those changes.

Boundaries#

• Checkpoint doesn't replace a Git commit.
• Checkpoint doesn't automatically resolve an external process editing the same file at the same time.
• A Checkpoint only belongs to its own Session and Workspace.
• Your uncommitted edits are never silently overwritten.

Actually restoring files and conversation state happens through Rewind.

Rewind: roll back conversation and files to a message#

Rewind rolls a Session and Workspace back to the recovery point tied to a specific message. It's not an ordinary message deletion — the operation actually changes real files.

Starting one#

Choose Rewind on a recoverable message in the Session timeline. Before executing, kxen checks:

• Whether an active run currently exists.
• Whether the Checkpoint belongs to this Session and Workspace.
• Whether the working tree has unsaved changes.
• Whether the scope of the restore needs your confirmation.

What it changes#

Rewind deletes the Session history after the target message, and restores the file state the Checkpoint recorded. Any subsequent tool results, Approval records, and assistant output stop belonging to the current timeline.

Protecting your own edits#

When a file has changed outside the Checkpoint, Rewind never silently discards those changes. The UI has to show you the scope of impact, and stop the operation when it can't restore safely.

Compared to Fork#

Fork creates a new Session from a historical message, keeping the original Session and current file state intact. Rewind modifies the current Session and file state directly.

Use Fork when you just want to keep exploring from an old conversation. Only use Rewind when you specifically need to undo an agent's file changes.

Worktree: isolate parallel edits with Git worktrees#

Worktree gives parallel agents or tasks their own independent working directory. It solves the problem of multiple write-capable execution units modifying the same file at the same time.

Where you find it#

The right-hand Dock's Worktree area shows the working trees bound to the current Session, and gives you a way to create and inspect them. The Workspaces board lets you see Worktree counts across projects.

What creating one gets you#

Every Worktree binds:

• Its source Git repository.
• An independent directory.
• A branch or detached state.
• The Session whose working directory sits inside it, and any agent or Team that Session dispatches.

Once created, file tools, Shell, LSP, and Git status should all operate on the Worktree directory — never the main Workspace directory.

An agent tool can create a dedicated Worktree for a single Subagent dispatch. Team members don't currently each bind a different Worktree — if you need to isolate an entire Team, create the Session inside the Worktree directory first.

When to use it#

• Two execution agents implementing independent features in parallel.
• A review task that needs a fixed baseline.
• An entire Team that needs an isolated branch.
• A long task that shouldn't touch your current working tree.

Git boundary#

Worktree only provides directory isolation — it never auto-merges commits. Once a task finishes, you still need to check the diff, run verification, and let yourself or the main agent decide how to commit and merge.

Never let two Worktrees write to the same branch. Before deleting a Worktree, confirm there are no uncommitted changes and no run still bound to it.