Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Stop the agent before it can write again, preserve the current workspace, and identify exactly which files changed. Then recover from the narrowest source that contains the wanted version: an agent or editor checkpoint, Git history, an agent-specific rewind, or a snapshot of the hosted workspace. Verify the restored files and project checks before allowing the agent to continue.
No single rollback restores everything. Checkpoints and rewinds generally cover selected workspace files, Git covers content that was actually stored in repository history, and cloud snapshots cover only the volumes and points in time they captured. Terminal commands, network requests, deployments, and edits to external services need separate investigation and recovery.
1. Stop the damage and preserve evidence
If the agent is still deleting, overwriting, or running a command you do not understand, stop or cancel it where that is safe. Do not immediately run a cleanup script, broad reset, second restore, or other command that could overwrite the only remaining copy. The VS Code recovery guide recommends first assessing the changed-file list, recent tool calls, terminal output, and effects outside the editor: Get an agent back on track.
Keep the damaged workspace in its current state long enough to investigate. If you make a safety copy, make it without deleting or replacing the original. Write down the agent session, the request that preceded the failure, the approximate time, and any command that may have run. This timeline helps you choose a recovery point that is old enough to contain the intended files but not so old that it discards good work.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
- Stop the agent or cancel its operation before accepting another suggestion.
- Do not close or clean up the session until you know whether it contains a checkpoint or rewind point.
- Record affected paths, including files that were deleted, renamed, emptied, or only partially overwritten.
- List possible non-file effects such as package installs, database writes, deployments, network calls, or changes in a hosted service.
2. Map what changed and when
Inspect the agent and editor history
Start with the editor’s changed-file view or the agent session history. Look for the request immediately before the unwanted operation, the tools it called, and the terminal output returned after each call. An agent may report that a task succeeded even when a command failed, so treat the recorded files and command output as evidence rather than relying on its summary.
Inspect Git without changing anything
From the repository root, run read-only status and diff commands:
git status --short
git diff -- path/to/file
git diff --cached -- path/to/file
git log --oneline --decorate -5git status --short distinguishes modified, deleted, staged, and untracked paths. The unstaged diff shows what is currently different from the index; the cached diff shows what is staged. The recent log tells you whether the desired version exists in a commit. Use a path after each diff command when investigating one file so you do not overlook useful edits elsewhere.
Classify every affected file
| Observed state | What it means | Likely recovery source | Important limitation |
|---|---|---|---|
| Changed by the agent and covered by a checkpoint | The editor captured a pre-request workspace state. | That editor’s checkpoint restore | Availability and capture scope vary; it is not a permanent backup. |
| Tracked and committed | The wanted content exists in a commit or another Git object. | Git restore, a known commit, reflog, or reachable object | Inspect the target before restoring so good later edits are not lost. |
| Tracked but only local or staged | The content is in the working tree or index but may never have been committed. | Checkpoint, editor history, or a carefully chosen file-level operation | Git history cannot recreate content that was never stored in Git. |
| Untracked or never recorded | No repository object or checkpoint is known to contain it. | Agent/editor history, operating-system backup, or service-specific history if available | Recovery is uncertain unless another copy exists. |
| External effect | A command, request, deployment, or service changed something outside the workspace. | The affected service’s logs, rollback, snapshot, or recovery controls | A file checkpoint does not reverse the external action. |
Mark each path as “keep,” “restore,” or “investigate.” A single agent request can contain both valuable edits and destructive ones, so restoring the entire workspace may be broader than necessary.
3. Choose the recovery source that actually contains the wanted version
| Recovery source | Best use | Scope | What it cannot promise |
|---|---|---|---|
| Agent/editor checkpoint | Return files to the state before a known request. | Affected workspace files and, in supported VS Code sessions, chat history. | No reversal of completed terminal commands, network requests, deployments, or external-service changes. |
| Git | Recover tracked content from a commit or investigate moved references. | Files and repository objects stored by Git. | Uncommitted content that Git never recorded. |
| Agent-specific rewind | Undo changes captured by a particular agent session. | Tracked, agent-written files within that session’s rewind point. | Files outside capture rules, changed-by-user files, remote-backed or busy sessions, and oversized or very large turns may be skipped. |
| Hosted-workspace snapshot | Roll back a hosted environment when a provider snapshot exists. | The volumes and timestamp included by that provider. | Anything outside the snapshot scope or created after it. |
| Other backups or service history | Recover files or external data not covered above. | Whatever the operating system, editor, or service retained. | Availability and retention differ by environment. |
Use the source with the smallest scope that contains all files you intend to recover. That approach preserves later work and makes verification easier.
4. Restore an editor or agent checkpoint
When a checkpoint is the right choice
In a supported VS Code agent session, checkpoints are created before requests. Navigate in the agent conversation to the request immediately before the destructive change and use the session’s checkpoint restore action. The operation can restore affected workspace files and the associated chat history. The exact controls can vary by VS Code version and session type; consult the official procedure at code.visualstudio.com/docs/agents/guides/get-agent-back-on-track.
Know the boundary
VS Code describes checkpoints as temporary and explicitly says they do not replace Git. A checkpoint restore does not undo a shell command that already ran, a network request, a deployment, or a change made through an external service. After restoring files, return to the terminal and service logs to handle those effects separately.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Verify the result
- Review the restored-file list and confirm that each intended path is present.
- Inspect the editor’s diff against the restored point.
- Run
git status --shortand inspect any remaining differences. - Run the project’s normal build, test, lint, or migration checks before asking the agent to edit again.
5. Recover tracked files with Git
Restore one file from the current commit
When the desired version is the current HEAD version, restore only the named path:
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
git restore --source=HEAD -- path/to/fileThis replaces that working-tree file with the version from HEAD. If the wanted version is in an older commit, identify it first, then use its object name:
git log --oneline -- path/to/file
git restore --source=<commit> -- path/to/fileReplace <commit> with the actual commit ID. Quoting a path with spaces is safer in a shell. Do not use a repository-wide restore or reset until you have reviewed which good edits it would overwrite. The official command reference explains the source and path behavior: git-scm.com/docs/git-restore.
Separate staged and working-tree decisions
If the index contains a useful version, inspect it with git diff --cached -- path/to/file before changing either copy. To remove a file from the index while leaving its working-tree contents in place, use a path-specific command such as:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →git restore --staged -- path/to/fileThat command does not reconstruct deleted content; it only changes staging. Choose the source and destination deliberately when both the index and working tree contain different versions.
Investigate a moved branch or lost commit
If the agent changed branch or reset a reference, inspect the reflog:
git reflog --date=localThe reflog records recent movements of local references, so it can reveal the commit that HEAD pointed to before an unwanted reset or checkout. If an object is no longer reachable from a reference, Git’s object checker may locate it:
git fsck --lost-foundRead the output and inspect candidate commits or blobs before using them. Reflogs and unreachable-object searches are investigative tools, not guarantees: they cannot manufacture an uncommitted file that Git never stored. See the official references for git reflog and git fsck.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallVerify every Git restore
After a file-level restore, run:
git status --short
git diff -- path/to/file
git log --oneline -1Confirm that the path contains the intended version, the current commit is the one you expect, and no unrelated files were replaced. Run project checks before committing the recovery.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
6. Use an agent-specific rewind when its rules fit
GitHub Copilot CLI rewind requires an existing rewind point and file tracking. Its documentation says it restores files Copilot changed; if a file’s current content no longer matches what Copilot last wrote, the rewind skips that file. It also documents these capture limits: individual files larger than 10 MB are not captured, a turn changing more than 500 files is not captured, file tracking must be available, and remote-backed or busy sessions are ineligible. Read the operation’s preview and skip notices before confirming it at Canceling a GitHub Copilot CLI operation and rolling back changes and Rolling back changes made during a GitHub Copilot CLI session.
Use rewind when the damaged files were changed by that session and the rewind point predates the damage. If the preview omits a file, stop and recover that path from Git, an editor checkpoint, or another backup instead of assuming the rewind is complete. Afterward, inspect Git status and diffs; a rewind is not a substitute for validation.
7. Restore a hosted workspace from a snapshot
When the files live in a hosted development environment and a provider snapshot predates the incident, use that provider’s documented restore procedure. For example, Amazon Web Services’ WorkSpaces Personal procedure describes restoring root and user volumes from snapshots. The result depends on which volumes were included, when the snapshot was taken, and what retention is available in that account.
Before confirming a volume restore, compare the snapshot timestamp with the damage timeline and identify any good work created afterward. A snapshot rollback can remove later changes across the volume, not just the file the agent damaged. Treat the provider’s scope and recovery-point objective as authoritative for that service; do not generalize the procedure to every hosted workspace.
8. Handle commands and external effects separately
Make a second inventory for actions that did not merely change local files:
- Package, database, or migration commands that changed local or remote state.
- Deployments or infrastructure changes that may already be active.
- Network requests that created, deleted, or modified records.
- Edits made through issue trackers, cloud consoles, or other integrations.
Use terminal output, command history, deployment history, and the affected service’s audit or activity log to determine what happened. Then use that service’s own rollback, restore, or correction control. Neither a VS Code checkpoint nor a file-focused agent rewind reverses these actions. If you cannot establish the effect, pause further automation and involve the owner of the affected system before retrying.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.9. Recovery branches for common failures
The checkpoint is unavailable
Continue with the Git classification. Look for a commit, reflog entry, or reachable object containing the desired file. If the file was never committed, inspect editor history, operating-system backups, or service history. Do not claim success merely because the directory exists; the missing content may have had no surviving copy.
Git restore would discard useful edits
Restore a single path from a specific source, or first preserve the current file outside the operation. Compare the proposed source with git diff and the commit history. A broad reset is appropriate only when you have confirmed that every affected change should be discarded.
Rank #4
- Easily store and access 4TB of content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
A rewind skips one or more files
Read the skip reason. A file may have changed after the agent wrote it, exceed the documented size limit, or belong to a turn that exceeded the changed-file limit. Recover skipped paths independently and merge only the intended portions.
The files look correct but the application is still broken
Check for external effects, generated files, dependency changes, environment variables, migrations, or a deployment that the file restore did not reverse. Re-run the project’s normal checks from a clean, understood state and inspect service logs before giving the agent another task.
10. Validate before resuming the agent
Validation is a gate, not a formality. Confirm all of the following:
- The restored file list matches the paths you marked for recovery.
- Git shows the expected branch, commit, staged state, and remaining diff.
- Deleted files are present only when they belong in the intended version.
- Build, test, lint, type-check, and migration checks appropriate to the project pass or have documented failures.
- External systems show the expected deployment or data state.
- You have recorded constraints for the next request, including files and systems the agent must not touch.
Only after these checks should you resume the agent. Give it a narrow next task, state the acceptance criteria, and ask it to show the proposed file changes before it performs another high-impact operation.
11. Prevent the next destructive recovery
Commit a known-good baseline
Before a large or unfamiliar task, create a Git commit that builds and passes the project’s relevant checks. A clean starting commit gives you a precise restore point and makes later diffs easier to review.
Define boundaries and acceptance criteria
Tell the agent which directories, services, credentials, and production systems are out of scope. Specify observable results such as tests that must pass, files that may change, and commands that require approval. The VS Code guidance recommends setting boundaries, using a plan for significant risk, and keeping permissions appropriate for unfamiliar repositories: VS Code’s recovery guidance.
Review early
Inspect the first meaningful diff instead of waiting for a long task to finish. Early review catches a mistaken assumption while the agent’s checkpoint, Git history, and tool log are still easy to correlate.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Consider command-level snapshots carefully
The bashback project describes capturing working-tree file side effects around shell commands and undoing them. That description is a vendor claim, not an independent guarantee. Before relying on such a tool, verify platform support, which files and operations it covers, how it handles external effects, and what restoration behavior you can test in your environment.
The practical decision rule
Recover the smallest verified set of files from the newest source that definitely contains the intended version. Use a checkpoint for a known pre-request workspace state, Git for content stored in repository history, an agent rewind only when its capture rules include the files, and a hosted snapshot only when its volume and timestamp match the incident. Investigate terminal and external changes on their own, then verify files, commits, tests, and service state before the agent writes again.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
