Skip to main content
o4 gives you two ways to go back. /undo reverses o4’s most recent file edit. /rewind goes back to an earlier turn: it restores your files as they were at the end of that turn and cuts the conversation back to that point. Use /undo for a single bad edit and /rewind when a whole line of work went wrong.

​
Undo the last edit

/undo restores the file that o4 changed most recently to what it was before that change, and reports Restored <path>. Run it again to step further back. Alt+U does the same from the keyboard. What /undo covers:
  • Changes the model made with its edit and write tools. o4 keeps the previous contents of the file before each one.
  • Up to the last 50 changes since you started o4. The oldest are dropped first. The history is shared by all tabs, so /undo reverses the newest change from any of them.
  • One file per step, newest first.
What it doesn’t cover:
  • New files. Writing a file that didn’t exist isn’t recorded, so /undo doesn’t delete it.
  • Changes made by shell commands, such as sed, mv, rm, formatters, or code generators the model ran.
  • Notebook edits.
  • Changes you made yourself.
  • Edits made by subagents.
  • Edits from before you started or resumed o4. The undo history starts empty in each o4 process.
If o4 can’t restore a file, for example because it was deleted or moved since the edit, /undo shows Undo failed: with the reason, and that step is still removed from the history. The next /undo goes on to the change before it. The model can also use an undo tool to revert its own last edit, from the same history. It asks for your approval the first time. Unlike /undo, the tool keeps the step in the history if the restore fails. /undo doesn’t touch the conversation. The model still remembers making the change, so tell it what you undid and why.

​
The Undo chip

After some turns, o4 shows action chips below the reply, and the last one can be Undo (see Prompt Mode). The Undo chip doesn’t work like /undo: it restores every file in your working tree to the latest checkpoint, the one taken when the model finished its last response, and shows Files restored from checkpoint #<n> — conversation unchanged. It doesn’t ask first, and it can delete untracked files, like a rewind (see the warning under Rewind to an earlier turn). Since that checkpoint was taken after the model’s changes, it only reverses changes made since then.

​
Rewind to an earlier turn

At the end of every turn, o4 saves a checkpoint of your working tree. /rewind goes back to one of them.
/rewind with no arguments opens the Time Machine, a list of the session’s turns with a preview of each prompt and how many files and lines it changed. Rewinding to a turn:
  • Restores the files in your working tree to how they were at the end of that turn.
  • Removes the later turns from the conversation, so the model continues from that point as if they never happened.
  • Asks you to confirm first if the model’s edits in later turns changed files: Rewind and revert files?, with up to 20 of the files listed. Press y or Enter to rewind, or n or Esc to cancel. Only edits made with the model’s edit and write tools count here, so o4 can rewind without asking even when shell commands or you changed files since.
When it’s done, o4 shows Rewound to turn 3. Type to continue. The Time Machine can’t rewind while the agent is working; it shows Cannot rewind while agent is running. If you type /rewind or /rewind <n> while the agent is working, o4 queues it and runs it when the turn finishes. /rewind list opens right away. To rewind sooner, stop the agent with Esc first. /rewind list shows the last 10 checkpoints with their turn, prompt preview, number of changed files, and short commit ID. It’s for reference only: its footer says Enter rewind, but Enter just closes the list, so rewind from the Time Machine. /rewind <n> goes to checkpoint number n without asking first, and shows Rewound to checkpoint #<n>. Checkpoint numbers count every checkpoint, so they don’t match turn numbers, and /rewind list doesn’t show them. If n is the checkpoint a Time Machine row points to, /rewind <n> restores files and cuts the conversation, like choosing that row. For any other checkpoint o4 still keeps, it restores your files only and leaves the conversation as it is. A number o4 doesn’t have shows No checkpoint found, and an argument that isn’t a number shows Usage: /rewind [list].
To open the Time Machine with a key, bind toggle_time_machine in your configuration. It has no key by default. See Keyboard shortcuts.
Rewinding is destructive. It changes every file in the working tree to match the checkpoint, including changes you made yourself after that turn, and it deletes untracked files that weren’t there at the checkpoint. If you started o4 in a subfolder of the repository, it deletes such files only inside that folder. It also replaces what you had staged: afterwards, the difference between your last commit and the checkpoint is staged, including files that were untracked at the checkpoint. Your branch and commits don’t change, and files ignored by .gitignore aren’t touched. Commit or stash anything you want to keep before you rewind.

​
Fork instead of rewinding

If you’re not sure you want to throw the later turns away, fork instead. In the Time Machine, select a turn and press f. o4 creates a new session with the conversation up to that turn and opens it in a new tab named fork @<turn>. The current session and your files stay as they are. The fork gets the checkpoints up to that turn, so its own Time Machine can go back further. You can’t fork while the agent is working or while background tasks are running. A fork copies the conversation only, not the files. Both sessions work on the same files on disk. See Sessions for more on forks.

​
How checkpoints work

Checkpoints need git. o4 stores each one as a snapshot of every file in your working tree that isn’t ignored, tracked or untracked, without changing your branch, your staged changes, or your working files.
  • Snapshots are git objects in your repository, kept alive by refs under refs/o4/<session-id>/. They don’t appear in git log or git branch.
  • o4 creates one each time the model finishes a response, so a prompt that makes the model use tools several times gets several checkpoints. The Time Machine shows one row per prompt, and rewinding to it goes back to the last checkpoint of that prompt.
  • A session keeps its most recent 50 checkpoints. They’re saved with the session, so /rewind still works after you resume it.
Outside a git repository, o4 can’t create checkpoints, and /rewind has nothing to go back to. /undo still works, since it doesn’t use git.
Checkpoint refs make git keep those snapshots, so a long session in a large repository takes up some disk space. Old refs aren’t cleaned up automatically. To remove them, delete the refs under refs/o4/, for example with git for-each-ref --format='%(refname)' refs/o4/ | xargs -n 1 git update-ref -d.

​
Checkpoint tools for the model

The model has two tools for marking a point it can go back to, separate from the checkpoints above. Both need git. See Tools.
  • checkpoint_create adds a git tag named o4/checkpoint/<plan>/<timestamp> at your current commit. The plan part is manual unless the model names a plan. The tag records your last commit only, not uncommitted changes. It asks for your approval the first time.
  • checkpoint_restore restores tracked files from such a tag, with git checkout <tag> -- ., and stages them. It refuses if you have uncommitted changes, unless the model passes force. It doesn’t move your branch, and it doesn’t delete files that were added after the tag. It asks for your approval every time.
These tags stay in your repository until you delete them, for example with git tag -d <tag>. They show up in git tag, and git push --tags would push them.

​
What can’t be undone

Neither /undo nor /rewind can reverse effects outside your working tree:
  • Commits, pushes, branch changes and other git operations the model ran.
  • Files outside the repository, and files ignored by .gitignore. The one exception: /undo can put back a file there that the model changed with its edit or write tools.
  • Installed packages, database changes, network requests, and anything else a command did outside your files.
To limit what the model can do in the first place, use permissions and the sandbox.