Reversible Work: Rewind, Sessions, and Parallel Branches

Reasonix’s idea of undo is deliberately narrower than “reverse everything the agent did.” It separates structured file changes, conversation state, workspace ownership, and external side effects so you can tell what can be restored and what must remain a conflict. This chapter follows those lifecycles and gives you a practical basis for choosing a shared fork, controlled parallel work, or an isolated worktree.

Consider a migration that changes several files and then discovers a hidden compatibility problem. You may want to return the code to the state before the turn, keep the conversation that led there for reference, or continue from an earlier decision without destroying the newer experiment. A long-running agent also creates a second problem: another window, child worker, or process may be changing the same workspace. Reversibility is therefore both an undo problem and an ownership problem.

Rewind restores structured effects, not every side effect

Reasonix checkpoints are file snapshots, not Git commits. A checkpoint opens for a user turn. Before a previewable file mutation, the host captures the file’s turn-start content once per path. If the operation creates a file, the snapshot records that the file did not exist; restoring that state deletes the created file. If the operation modifies or deletes a file, the snapshot keeps the previous content.

This gives the user three meaningful scopes. Code rewind restores the earliest saved preimage for each affected path from the selected turn onward. Conversation rewind creates a new conversation head at a turn boundary. Both creates the new head first and then restores the structured file state. An undo operation can restore the after-images of a rewind when the user changes direction again.

The sequence is important. A conversation rewind is not a truncation. It preserves the previous chain as another version, so the user can compare or return to the abandoned direction. A code rewind is not a Git reset: it operates on the snapshots Reasonix captured for structured edit tools and does not alter Git history. This makes it useful in a non-Git directory and keeps the agent’s undo feature separate from commits, branches, and staging.

The boundary is just as important as the capability. Reasonix does not path-track arbitrary Bash side effects. A shell command that removes a file, moves a directory, writes a database, or deploys a service may have real consequences that a file snapshot cannot reconstruct. An edit-tool deletion can be restorable because the host captured its preimage; a shell rm is not automatically restorable. The system reports this difference rather than offering a misleading universal undo button.

External edits are protected as well. Before restoring, Reasonix compares the current existence, content identity, and mode with the last state it recorded. If another process changed the file after the agent’s operation, restoring the old snapshot would overwrite a change the user may want.