# When Claude Code goes wrong (and it will) **Author:** Ivan Misic **Published:** 2026-01-11 **URL:** https://ivanmisic.net/blog/ai-tools/when-things-go-wrong **TL;DR** Assume Claude Code will sometimes make the wrong change. Inspect the diff after meaningful work and keep both a recent recovery option and a durable Git restore point. - Run `/diff` and test the behavior you requested; Claude's summary is navigation, not evidence - Use double-Escape or `/rewind` for direct file edits captured by recent session checkpoints - Checkpoint recovery is limited to the latest 100 checkpoints and 30 days, and it does not cover shell commands, external tools, or another session - Use Git for durable history, especially before structural work - Handle one task at a time, and use `/clear` when old instructions or a confused conversation pull the work in the wrong direction Assume that Claude Code will sometimes misunderstand the task or change the wrong file. I inspect the diff after each meaningful change and keep a recovery point before larger work, because the useful skill is catching the mistake before more changes depend on it. ## Your Undo Toolkit Start by inspecting what changed with `/diff`. If Claude edited files directly, press `Esc` twice or run `/rewind`. Choose the prompt before the mistake, then restore the code, conversation, or both. Checkpoints do not cover file changes made through shell commands, external tools, or another session, so use Git for a permanent restore point. Know the edges before you rely on it. Claude Code keeps snapshots for the 100 most recent checkpoints in a session, and deletes checkpoints along with the session after 30 days. That makes rewind an excellent answer to "I broke it ten minutes ago" and a poor answer to "I broke it last month." For one small, understood edit, you can ask Claude to reverse it: ```text Undo the last change to index.html ``` Inspect the diff again rather than trusting the confirmation. **Start fresh** ```text /clear ``` `/clear` starts a fresh session. Your files remain unchanged, while project instructions and auto memory load again. Claude reads project files as the new task requires them. I use `/clear` when the task changes or the conversation contains conflicting instructions. A fresh session keeps the files and project rules without carrying the old discussion. **Version control (you'll learn this in Module 4)** Use Git when you need a durable restore point outside the current Claude session. The later module covers the setup.
![Recovery decision map separating Claude Code checkpoint rewind, conversation clearing, and Git version control by the type of problem](/images/blog/ai-tools/claude-code-recovery-paths.png)
Current Claude Code also keeps checkpoints for direct file edits: press Esc twice or use /rewind to restore code, conversation, or both. Checkpoints do not track Bash commands, external changes, or background subagent edits, so they complement Git rather than replace it. See the official checkpointing documentation.
## Common Problems and Fixes What typically goes wrong and what to do about it: | Problem | What Happened | What to Say | |---------|--------------|-------------| | Wrong file edited | Claude changed a file you didn't mean | "Undo the changes to [filename]. I meant [correct filename]" | | Changed too much | Asked for a small fix, got a rewrite | "That's too many changes. Undo everything and only change [specific thing]" | | Claude seems confused | Responses don't make sense | Type `/clear` and start a new conversation | | Can't do something | Claude says it can't | Try rephrasing. If still stuck, break the task into smaller pieces | | Made things worse | The fix created new problems | "That made it worse. Undo it. Now it's doing this: [describe]" | Describe the observed result, name the file when you know it, and choose whether to undo the change or ask for a smaller correction. ## Give Claude Something to Search For When you're hunting for a problem, give Claude specific text to find. Copy-paste the exact error message. Quote the specific sentence that's wrong. Include the code snippet that isn't working. Same principle as searching your email: you find things faster when you remember a specific phrase from the message rather than vaguely describing what it was about. ```text I'm getting this error: "Cannot read property 'length' of undefined" It happens when I click the submit button ``` That exact error message gives Claude a search target. It can grep through your files and find exactly where that might originate. Vague descriptions like "there's a JavaScript error somewhere" mean Claude has to guess. Same with content issues: "The paragraph that starts 'Welcome to our store' has a typo" is faster to fix than "there's a typo on the home page somewhere." ## The Screenshot Trick For a visual problem, I provide a screenshot together with the page, viewport, expected result, and the part that looks wrong. Take a screenshot of the problem. Paste it with the image shortcut supported by your terminal, or give Claude the image path. Current CLI shortcuts include `Ctrl+V`, `Alt+V` on Windows, and `Cmd+V` in iTerm2. Then say: ```text This is what it looks like right now. See how the menu is covering the main content? I want the menu to stay at the top and the content to start below it. ``` The screenshot shows the current state, while the description defines what the correct result should be. This works for: - Layout issues ("this overlaps that") - Color problems ("this text is invisible on this background") - Spacing issues ("these elements are too close together") - Design comparisons ("make it look more like this screenshot") ## When Context Pulls the Work Off Course Run `/context` when you want to see what is using the context window. Use `/compact` to shorten a session you still need, or `/clear` when you are moving to a separate task. A long session is not automatically bad, but old instructions, large tool outputs, and contradictory decisions can pull later work off course. There is a more precise option in the same rewind menu. Pick the message where the session went sideways and choose to summarize from that point forward. The verbose debugging detour gets compressed while your original instructions stay intact, which is usually what you actually wanted from `/compact`. I start a new session when the task changes. The files and project instructions remain, while the old conversation no longer competes with the new request. ## The Golden Rule After each meaningful change, run `/diff` and test the behavior you asked for. Claude's summary can help you navigate the change, but the diff, test result, or browser check is the evidence. Before a complex change, ask Claude to explain its plan. This can expose a misunderstanding before it touches your files. If Claude's plan does not match my understanding, I ask it to explain the cause and proposed change before editing. Confidence is not evidence that the pattern fits this project. Review before you build the next change on top of it. Small mistakes become harder to isolate after several later edits depend on them. ## Prevention Is Better Than Recovery A few habits that reduce how often things go wrong: Be specific from the start. "Fix the footer" is an invitation for Claude to do something you didn't want. "Remove the empty gap between the footer links and the copyright text" is a fix Claude can make correctly. Do one thing at a time. "Fix the header, add a new section, and change the colors" is three separate tasks. Handle them one at a time so you can verify each one before moving on. Name your files. "Change the page" is ambiguous. "Change `about.html`" is clear. When you have more than a few files, always specify which one. ## How I Handle Mistakes I once asked Claude to "clean up the footer." It interpreted that as removing unnecessary elements and deleted my links, social icons, and copyright notice. Now I never say "clean up." I say exactly what to change: "remove the empty gap between the links section and the copyright text in footer.html." The specific instruction gives me a smaller diff to review and less to recover if Claude misunderstands it. The other thing I've learned is to save the work before big changes. Use checkpoints for quick session recovery and Git for durable history. A copied folder can help in a first experiment, but it is easy to forget which copy is current. > Next up: how project instructions give Claude the context it would otherwise need in every prompt. ## Frequently Asked Questions ### How do I undo a change Claude Code made? Start with `/diff` to see what actually changed. If Claude edited the files directly, press `Esc` twice while the prompt input is empty or run `/rewind`. Pick the prompt from before the mistake, then restore the code, the conversation, or both. ### How long do Claude Code checkpoints last? By default, a session keeps file snapshots for its 100 latest checkpoints. Checkpoints are deleted with the session after 30 days, but you can change that retention period in settings. Rewind is a good answer to "I broke it ten minutes ago" and a poor answer to "I broke it last month." ### Do checkpoints cover everything Claude Code changed? No. They cover direct file edits made by Claude's file tools. Changes made through shell commands, most subagents, external tools, or another session are not restored reliably, and linked files are skipped. Keep Git for a durable restore point, especially before structural work. ### Claude Code keeps making the problem worse. What should I do? Restore the last known-good state and start a new session with the evidence you have collected by then. Make one change and run one check. After five speculative fixes, you no longer know which change caused the failure. ### Why did Claude Code change the wrong thing? Often because the instruction left room for it. I once asked for the footer to be cleaned up and lost my links, social icons, and copyright notice. "Remove the empty gap between the footer links and the copyright text" leaves much less room for the wrong outcome.