// undo
Undo what the agent just did
Pick your tool. You get where its undo is, the exact steps, what the undo does not bring back, and how to save a restore point before the next big prompt.
Cursor
Where the undo is
In the Agent chat: click a checkpoint in the chat timeline, or use Restore Checkpoint on an earlier request.
Steps
- In the Agent chat, scroll up to the last request you sent before the app broke.
- Click the checkpoint in the chat timeline to preview your files as they were at that point.
- Restore it to revert all files to that state. You can also click Restore Checkpoint on that request, or the + button when you hover over the message.
- Restoring does not remove any messages from the chat. To continue from the earlier point with a shorter conversation, fork the chat from that message.
What it does not bring back
- Restoring reverts files only. Database rows or schema changed by a migration the agent ran, and anything it deployed or sent to an outside service, stay changed.
- Checkpoints are meant for Agent's own file edits. For anything a terminal command changed, such as installed packages or generated files, check git status after you restore.
- Checkpoints are local and separate from Git, so commits or pushes the agent already made are still in your Git history.
Before the next big prompt
Agent makes checkpoints on its own before significant changes, but they live only on your machine and are separate from Git. Before a big prompt, commit your working state with Git (git add -A, then git commit -m "before big prompt"). Cursor's docs say to use Git for permanent version control.
Claude Code
Where the undo is
Type /rewind, or press Esc twice while the prompt input is empty, to open the rewind menu.
Steps
- Run /rewind, or press Esc twice with an empty prompt input. If there is text in the input, the first double Esc clears it instead.
- The menu lists the prompts you sent in this session. Select the last prompt from before things broke.
- Choose Restore code to revert file changes and keep the conversation, or Restore code and conversation to rewind both.
- If you see "Restored the code, but skipped N files", those paths are symlinks or hard links. They keep their current contents, so fix them by hand.
What it does not bring back
- Files changed by Bash commands are not tracked. Anything Claude deleted, moved or copied with rm, mv or cp, and anything a script, installer or generator wrote, stays as it is.
- Edits made by most subagents, by other Claude Code sessions, or by you in your editor are normally not restored. Use git to revert those.
- Only files on disk are covered. Database changes, deployments, pushed commits and calls to outside services made during the session are not undone.
- Snapshots are kept for the 100 most recent checkpoints and deleted about 30 days after the session last saved one (setting: cleanupPeriodDays), so old rewinds can fail.
Before the next big prompt
Claude Code makes a checkpoint for every prompt you send, but it skips changes made by Bash commands. Before a big prompt, commit your work with git (git add -A, then git commit -m "before big prompt"). A commit also covers files changed by commands, and it lasts beyond the session. Claude Code's docs say checkpoints do not replace version control.
Lovable
Where the undo is
The History toggle in the top bar of the editor, or the + menu next to the chat input, then Project, then History.
Steps
- Click History in the top bar of the editor (or the + menu next to the chat input, then Project, then History).
- Click the last version that worked to open it in snapshot view. Use View code changes or Open preview in new tab if you want to be sure.
- Click Revert (Revert to this version). Lovable asks you to confirm and shows the date of that version. Confirm with Revert.
- To try a different instruction from that point instead, hover over your message, click Edit message, change the text and confirm Revert and resend.
What it does not bring back
- Reverting restores code only. Database records added or changed after that version, and migrations run against your data, are not rolled back.
- Your published app does not change when you revert. It keeps the last published version until you click Publish, then Publish changes. Edge functions are redeployed to match the reverted code.
- Very old versions can be previewed but not restored (Cannot revert this far back in history). In a project remixed from a Cloud project, versions from before the remix cannot be restored.
Before the next big prompt
Every change is saved as a version, so there is no save button. Before a big change, bookmark the version that works: select Bookmark in history on the activity card of a finished change, or click the bookmark toggle in the History panel. It then sits in the Bookmarks tab. A bookmark covers code only, not your database data.
Replit
Where the undo is
In the Agent tab of the Project Editor: Rollback to here on a checkpoint. The history icon in Agent chat shows the full timeline.
Steps
- Open the Agent tab in the Project Editor to see the checkpoints Agent created, each with a description and a timestamp.
- Find the last checkpoint where the app worked and select Rollback to here.
- Review the rollback warning. To also restore your development database, select Database in Additional rollback options. Then confirm.
- Check that your files, database and Agent context match that checkpoint.
- If you went back too far, click the history icon in Agent chat and select a later checkpoint to roll forward. Once you make new changes, those later checkpoints become an alternate branch.
What it does not bring back
- Your development database, unless you select Database in Additional rollback options. By default a rollback does not change it.
- Your production database. A rollback never restores it. Use a point-in-time restore for that.
- Your published app. Changes in the Project Editor do not replace the live release, so it keeps running what you last published until you select Republish.
- Anything the agent changed in outside services (payment providers, email, other APIs). Those changes happened outside your Replit App and stay.
Before the next big prompt
Agent creates checkpoints on its own at milestones, and each checkpoint is also a Git commit. Before a big prompt, make a manual Git commit in the Git pane too, as Replit suggests for long-term tracking. If the prompt will touch data, remember that rollbacks never cover the production database.
Bolt.new
Where the undo is
Version history: the clock icon in the top menu of your project. Recent versions can also be restored from the chat.
Steps
- In the top menu of your project, click Version history (clock icon).
- Click the last version that worked. Bolt loads a preview of it.
- In the top right, click Restore this version, then click Restore version to confirm. A success message appears in the chat.
- From the chat instead: scroll to the version, click the eye icon to preview it, click the return arrow icon, then click Restore version.
- On mobile: tap your project's name, tap Versions, then tap the restore button on the version you want. There is no preview first.
What it does not bring back
- Your Bolt or Supabase database. Restoring a project version does not change it, so rows, tables and schema changes made since then stay.
- Your published site. Changes to the project are not applied to it automatically, so it keeps what you last published until you click Update in the Publish menu.
Before the next big prompt
Bolt saves a version after every prompt that processes. Before a big prompt, open Version history, hover over the current working version and click Bookmark. You can also rename it with the pencil icon. For a copy outside Bolt, click the project title, then Export, then Download. None of these save your database.
v0
Where the undo is
The version controls attached to each generated message in the chat.
Steps
- In the chat, find the message that produced the last version that worked.
- Use the version controls on that message to inspect the version and view its diff.
- Restore that version. v0 creates a new, most recent version from the restored code, so the later versions stay in the history.
- If the broken code was already published, publish again (Publish, then Publish Changes). Deploying always uses the latest version, which is now the restored one.
What it does not bring back
- Your live deployment. Restoring does not redeploy, so the deployed site keeps the broken code until you publish again.
- Edits you made by hand in the code editor. They do not create versions, so a restore can replace them and there is no version to bring them back.
- A version holds code only. Data v0 changed in a connected database or other service through an integration, and environment variables in Settings, are not rolled back.
Before the next big prompt
v0 makes a version each time a message updates the code, so there is nothing to save for the agent's work. Before a big prompt, save any edits you made in the code editor with Save, because manual edits do not create versions. Note the message with the last working version so you know which one to restore.
Base44
Where the undo is
The Revert icon under each chat message, or Version History (clock icon) at the top of the AI chat.
Steps
- Hover over the message that broke your app, click the Revert icon under it, then click Confirm. The app returns to how it was just before that message, and later changes are undone too.
- To go further back, click the Version History icon at the top of the chat and click a version to load it in the preview.
- Click the More actions icon on that version and choose Revert to this version. This replaces your current draft in the app editor.
- If your live app is broken too, choose Publish this version on a version that works. Your live app only changes when you publish.
What it does not bring back
- Your app's data records. Version History covers code and design. Records the AI added, changed or deleted stay, unless you restore them in Dashboard, Data, Backup & Restore (Elite and Enterprise plans only).
- Your live app. Reverting changes your draft only, and the published version stays as it is until you publish.
- Anything your app or its automations already did, such as emails sent or calls to outside services. A version restore cannot take those back.
Before the next big prompt
Every AI change becomes a version, so there is nothing to save. For a big change, start a branch first: click Main next to your app's name at the top of the chat panel, then Create new branch. Main stays as it is until you merge. A branch still uses your real live data, so switch the preview to test data if your plan includes it.
Codex
Where the undo is
There is no rewind or undo command. In the Codex app, the review pane can revert the Git diff. In the CLI, use /diff and then Git.
Steps
- In the Codex app, open the review pane and choose Last turn to see what the most recent turn changed.
- Revert a single hunk or file you do not want, or click Revert all in the review header to discard the entire diff.
- In the CLI, type /diff to see the Git diff, including files Git is not tracking yet. Then restore files with Git, for example git restore <file>.
- If you committed before the prompt, you can always return to that commit with Git.
What it does not bring back
- The review pane shows your whole Git repository, not only Codex's edits. Revert all also discards your own uncommitted changes.
- Reverting works on the Git diff. Changes Codex already committed or pushed, and files Git ignores (such as .env or node_modules), are not reverted this way.
- Anything outside your files: database rows or schema changed by a command Codex ran, packages installed globally, deployments and calls to outside services.
- The project must be a Git repository. Without Git there is no diff to revert, and the app asks you to create one.
Before the next big prompt
OpenAI's Codex docs say to create Git checkpoints before and after a task so you can revert changes. Before a big prompt, commit: git add -A, then git commit -m "before big prompt". For risky work in the CLI, type /worktree to continue in a separate Git worktree so your main checkout stays untouched.