An AI coding agent can edit many files and run commands while you focus on the result. That is useful when you are building an app, but a plausible looking change can remove a working screen, rewrite configuration or delete files the agent did not understand. The safest time to plan a recovery route is before the first edit, while the project still works.
This guide is for a maker using an agent on a local app project. It combines Git's documented file history with Claude Code's published checkpoint limits. The same questions apply to other coding agents, though their permission and undo controls differ. It is a general workflow, not a report that VIBPS tested a particular agent or a claim about any one viral deletion story.
Save the state you actually need to recover
Start with the project in a working state. In a Git repository, run `git status` and look at the changed and untracked paths. Commit the project files you would want back, then confirm that the commit exists before starting the agent's task. A commit gives those recorded files a clear restore point. If the project is only on your laptop, copy the committed repository to a remote you control or keep a separate backup; an accident that removes the local repository can remove its history too.
Pay special attention to files Git does not contain. A new image, exported design, local database, uploaded media folder or ignored file may be absent from the commit. Git's documentation says ignored files are not added by default. Copy valuable local files to a separate, access-controlled location and check that the copy opens. Keep credentials and private customer data out of a public repository and out of a shared backup. A backup is useful only if you can identify what it contains and restore it.
Source: Git documentation: what status shows
Source: Git documentation: adding files and ignored-file behavior
Give the agent a smaller place to work
Use a new branch or a separate working copy for a task that could disturb a working app. Tell the agent which feature and files it should change, what behavior must remain, and which directories or services are off limits. If it needs access to a live database, payment account or production deployment, stop and decide whether a test environment can answer the question first. A code snapshot does not bring back database rows, storage objects or messages sent through an external service.
Read the agent's permission settings rather than assuming every tool asks before acting. For example, Claude Code documents different approval behavior for file edits and shell commands, plus configurable rules. Keep a confirmation step for commands or access that could alter more than the requested project area. When a task is unclear, ask for a short plan and review its file scope before approving broad changes. A written instruction can guide an agent, while actual access and backup boundaries limit what a mistake can affect.
Source: Claude Code documentation: permissions and tool approvals
Review one useful change at a time
After a small unit of work, inspect the changed-file list and the diff. Check the behavior in the app, including the route a real user would take, rather than accepting a successful build as the whole test. If the feature works, make another commit. If it fails, the small diff makes the cause easier to find and the previous commit gives you a known point to return to. Keep a note of any manual changes you make while the agent works so a later undo does not silently erase your own work.
What if the agent already deleted a file?
Stop the agent and inspect the current state before running a broad restore command. `git status` shows changed, deleted and untracked paths. If a deleted file was committed, Git's `restore` command can recover that specific path from a chosen commit. First inspect the source version and copy any newer work you still need: restoring a file replaces the current contents of that path. If the missing file was never recorded in Git, look in the separate backup or the storage service's own version history.
An agent's undo button has its own boundary. Claude Code says `/rewind` tracks edits made with its file tools, but a file changed only by a shell command is outside that tracking. It also documents limits for changes from other sessions, subagents, linked files and older checkpoints. Its own guidance is to keep using version control for durable history. Check the actual scope of your tool's undo before relying on it; do not assume it restores a database or a remote service.
Source: Claude Code documentation: checkpointing, rewind and limits
Source: Git documentation: restoring a specific file
A short preflight before the next agent task
- Confirm the app works and record its current Git status.
- Commit the project files you may need to recover; separately back up valuable untracked and ignored material.
- Use a branch or separate copy and keep production credentials and data outside the task when possible.
- Define the task and file scope, then review permission prompts for wider actions.
- Inspect the diff, test the user journey and commit a working increment before the next task.
The aim is to keep building while a mistake remains understandable and recoverable. When the app is ready for people to try, show what it actually does and where it runs. On VIBPS, makers can publish their app under an account and give people a way to find the software and follow its creator. A clear, working product remains the best starting point for that introduction.