Three real options, from safest to most drastic. Which one applies depends entirely on whether the project is under version control — which is the actual point of this article.
If the project is under version control, this is the safe, reliable answer: git diff to see exactly what changed, git checkout -- <file> to revert a single file, or git reset --hard for a full rollback to the last commit. This is precise and doesn't depend on memory or guesswork.
Within the same session, describing what to undo often works well — Claude Code can usually reconstruct the prior state accurately while the context is still fresh. This isn't a guaranteed built-in undo feature, though, so don't rely on it as your only safety net.
A copied file or folder from before the change works in a pinch, but it's easy to forget to make one, and it gives you no real history of what changed and when — a stopgap, not a real strategy.
The free guide covers reading a diff carefully — the habit that prevents most unwanted changes before they happen.
Get the Free Guide →Start now, even for a small project — a real version-control habit is the single biggest factor in how stressful an unwanted change feels, and it takes minutes to set up.
You can ask it to revert a specific edit within the same session, and it can usually do so accurately if the context is still fresh — but this depends on session memory, not a guaranteed undo feature, which is why git remains the reliable fallback.
It works in a pinch, but it's easy to forget and doesn't give you a real history of changes — worth using only until you set up proper version control, not as a long-term habit.