Restoring Deleted Files Safely After a Bad Execution

It is the split-second silence that follows a “Bad Execution.” You have just issued a high-level directive to your AI coding agent—perhaps a request to “refactor the utility folder and remove unused exports”—and you watch the terminal scroll with terrifying speed. Suddenly, you realize the agent interpreted “remove unused exports” as “delete the entire src/utils directory because the test files weren’t currently imported.”

In the world of Vibe Coding, where we trade manual keystrokes for high-velocity intent, the risk of a destructive hallucination is a mathematical certainty. The faster you move, the more critical your “Undo” button becomes. This article is your comprehensive guide to the safety protocols, recovery tools, and defensive architectures required to survive a rogue AI execution and restore your project to a state of grace without losing a single line of progress.

The Anatomy of a Bad Execution

In an intermediate Vibe Coding workflow, we often use tools like Cody Master, which operates on a Research -> Strategy -> Execution lifecycle. The “Execution” phase is where the rubber meets the road—and where the tires often blow out. A “Bad Execution” usually stems from one of three failures:

Contextual Blindness: The AI fails to “see” that a file it is about to delete is actually a dependency for an untracked or peripheral module.
Shell Command Hallucination: The agent generates a rm -rf command with a wildcard that matches more than intended (e.g., rm -rf src/components/*.ts instead of src/components/Legacy/*.ts).
State Mismatch: The agent’s internal representation of the file tree is out of sync with the actual disk state, leading it to “cleanup” files it believes are redundant.

When these failures occur, your immediate priority is not fixing the code—it is preserving the history.

Core Concepts: The Safety Stack

To restore files safely, you must understand the layers of protection provided by a modern development environment. We visualize this as a “Safety Stack,” moving from the most volatile to the most permanent.

1. The Git Index (Staging Area)

The index is your first line of defense. Most high-quality AI agents are instructed to git add changes but not git commit them unless explicitly told. If an agent deletes a file and then stages that deletion, the file still exists in the Git object database, even if it is gone from your working directory.

2. The HEAD Commit

The most recent stable state of your project. If you are following the cm-planning and cm-quality-gate protocols, you should never start an execution phase without a clean HEAD.

3. The Git Reflog

This is the “Black Box” of your repository. Even if you perform a git reset --hard or delete a branch, Git keeps a log of every movement of the HEAD pointer for 30 to 90 days. If the file ever existed in a commit, it is in the Reflog.

4. Git Worktrees

For intermediate users, cm-git-worktrees is the ultimate isolation strategy. By running executions in a separate worktree (a separate directory linked to the same .git folder), a “bad execution” is physically isolated. If the agent deletes the entire directory in the worktree, your primary workspace remains untouched.

How It Works: The Recovery Toolkit

When you realize a file has been deleted, do not panic and do not close your terminal. Follow these steps in order of surgical precision.

Phase 1: Surgical Restoration (The “Oops” Recovery)

If you know exactly which file was deleted and you haven’t committed the change yet, the modern git restore command is your best friend.

The Problem: The AI deleted src/consts.ts and staged the change. The Solution:

# Unstage the deletion
git restore --staged src/consts.ts

# Restore the file from the HEAD
git restore src/consts.ts

This is the cleanest path because it doesn’t affect any other changes the agent might have made correctly in the same session.

Phase 2: The Time Machine (Git Reflog)

If the agent managed to commit the bad execution, or if you accidentally performed a git reset --hard trying to fix the mess, you need the Reflog.

The Command: git reflog You will see a list that looks like this:

abc1234 HEAD@{0}: reset: moving to HEAD~1
def5678 HEAD@{1}: commit: Rogue refactor that deleted everything
ghi9012 HEAD@{2}: commit: Stable state before execution

To recover:

# Create a new branch at the stable state
git checkout -b recovery-branch ghi9012

Now you can manually copy the missing files back into your main branch.

Phase 3: The “Conductor” Revert

If you are using the Conductor workflow (as seen in your project structure), you have access to a logical revert. Tools like conductor-revert (or the cm-revert skill) don’t just undo git commits; they undo logical work units (Tracks).

Because Conductor tracks the files modified during a specific “Task,” it can identify exactly which files were deleted during that specific intent-block and restore only those, preserving the metadata in your plan.md and findings.md.

Interactive Example: The Rogue Cleanup

Let’s walk through a real-world scenario. You are working on the Cody_Master_Web project. You ask the agent to “Clean up the scripts/ folder and remove any i18n scripts that are no longer used.”

The agent runs its research, identifies scripts/split-i18n.js as “unused” because it doesn’t see it in the package.json (even though you run it manually), and deletes it. It then proceeds to refactor scripts/translate-i18n.js.

1. Identifying the Damage

You run ls scripts/ and notice split-i18n.js is gone. First, check the status:

git status

Output: deleted: scripts/split-i18n.js modified: scripts/translate-i18n.js

2. The Surgical Strike

You want to keep the improvements to translate-i18n.js but you need split-i18n.js back.

# This brings back the file without touching the other modified script
git checkout HEAD -- scripts/split-i18n.js

3. Verification

Run your test suite to ensure the restored file is functional:

npm test test/i18n-sync.test.ts

Validation is the only path to finality. If the tests pass, you have successfully recovered from a bad execution while keeping the AI’s “good” work.

Best Practices for Defensive Vibe Coding

Prevention is always cheaper than recovery. To minimize the impact of bad executions, adopt these intermediate-level defensive patterns.

1. Atomic Commits Before Execution

Never start a major AI task (a “Directive”) on a dirty working tree. Use the cm-continuity protocol:

Turn Start: Check git status.
Pre-Execution: Commit current progress with a message like feat: stable state before AI refactor.
Post-Execution: Review the diff. If it’s a mess, git reset --hard HEAD is safe and instant because you committed 30 seconds ago.

2. The “Dry Run” Research Phase

Before allowing an agent to execute rm or destructive replace operations, demand a Research report. Use a prompt like:

“Research the scripts folder. List every file you intend to modify or delete and explain WHY it is safe to do so. Do not modify files until I confirm.”

This activates the Strategy phase and forces the agent to justify its destructive intent.

3. Leverage `cm-git-worktrees`

If you are working on a high-stakes refactor of the src/layouts or src/components folders, do not work in the root directory.

# Use the skill to create a sandbox
git worktree add ../cody-master-sandbox feature/cleanup-layout

Direct the AI to work only in that directory. If the agent deletes the wrong files, you can simply rm -rf ../cody-master-sandbox and git worktree prune. Your main project remains completely safe.

4. Use `cm-secret-shield`

Sometimes “deleted files” aren’t deleted—they are overwritten with empty data because the AI failed to read them properly. cm-secret-shield and similar linting procedures can detect when a file’s size drops by 90% unexpectedly, triggering an automatic stop before you commit the damage.

Advanced Technique: Recovering Untracked Files

What if the AI deleted a file that you just created and hadn’t yet added to Git? This is the nightmare scenario. In this case, git restore cannot help you because Git never knew the file existed.

1. IDE Local History

Most modern editors (VS Code, JetBrains, Cursor) maintain their own internal “Local History” or “Timeline.”

In VS Code, right-click the folder where the file was.
Select “Timeline” or “Open Local History.”
You can often find snapshots of files that were deleted outside of Git.

2. The “Black Box” Log

If you are using an agent that logs its output (like the logs/events.jsonl in your directory), search the logs for the file’s content. Many agents “Read” the file before deleting it. The content might be sitting in your terminal scrollback or a log file.

grep -C 5 "function splitI18n" logs/events.jsonl

You might be able to reconstruct the file from the agent’s own “Thought” or “Read” output.

Conclusion: Speed Requires a Safety Net

Vibe Coding is about the joy of creation at the speed of thought. However, that speed is only sustainable if you have absolute confidence in your ability to recover from a failure. By treating every AI execution as a “speculative” change and leveraging the Safety Stack—from Surgical Restores to isolated Worktrees—you transform the fear of “Bad Execution” into a minor operational speed bump.

Remember the Vibe Coding mantra: Plan deeply, execute surgically, and always keep the Reflog handy. Your deleted files aren’t gone; they are just waiting for you to call them back from the history.