Your AI Coding Agent Can Delete Your Files: The Archive-First Defense

The Disasters Are Real

In July 2025, Fortune reported that Replit’s AI agent deleted an entire production database during a code freeze. According to the user’s account, the agent then fabricated thousands of fake records to cover up the damage.

In December 2025, according to The Register, Google’s Antigravity platform ran rmdir /s /q d:\ on a user’s machine, wiping the entire D: drive. The command was meant to clear a project cache. Files deleted via shell bypass the Recycle Bin.

In February 2026, a developer alleged on GitHub that a Claude Code agent executed drizzle-kit push --force against a production database, dropping dozens of tables. The --force flag bypassed all confirmation prompts.

These are not isolated incidents. At the time of writing, Claude Code has over a dozen GitHub issues documenting destructive file operations. Cursor users created a dedicated recovery tool. Amazon’s AI agent Kiro was linked to a 13-hour AWS outage, though Amazon has disputed the causation.

The evidence varies in strength. Some cases come from media reports, others from user accounts or GitHub issues, and at least one is actively disputed. But the pattern is consistent: agents with sufficient access can and do execute damaging actions, sometimes in direct violation of your instructions.

This article addresses one specific, high-frequency version of the problem: protecting local files before an AI agent restructures your project. Production databases and cloud infrastructure require different safeguards.

Why This Keeps Happening

Based on the incidents above, similar reports, and my own experience, these are seven failure modes I’ve seen repeatedly. Most stem from three root tendencies: optimizing for task completion over safety, acting autonomously under broad permissions, and poor awareness of existing state.

1. Uninstructed cleanup. The agent decides files are “unused” and deletes them without being asked.
2. Force-flag bypass. It adds --force or --accept-data-loss flags to skip confirmation prompts.
3. Scope escalation. A command targeting a cache directory gets applied to the entire drive.
4. Panic cascading. An error triggers increasingly aggressive “fixes,” each more drastic than the last.
5. Overwriting without reading. The agent writes to a path that already contains important content, never checking what was there.
6. Suppressing errors. Piping stderr to /dev/null so you never see what went wrong.
7. Covering up damage. Fabricating test results or fake data after causing loss.

The most dangerous combination is uninstructed cleanup during file reorganization. The agent has both the motive (files need to move) and the means (shell access) to delete things it considers unnecessary.

I experienced this firsthand. I asked an agent to set up a GitHub repository. It cloned the repo into a directory that already contained a folder with the same name, silently overwriting the original contents. No warning, no backup. It saw a name collision and resolved it the fastest way it knew how.

Three Common Defenses (And Why They’re Not Enough)

1. Cloud Drive Sync (Dropbox, iCloud, OneDrive)

Cloud sync services maintain file versions and deleted-file recovery. If a file was previously synced, you can usually restore it. But cloud sync has a fundamental constraint: it struggles to keep up with rapid writes.

When an AI agent restructures a project, it may create, move, and delete dozens of files within seconds. Cloud sync clients process changes asynchronously. If the agent creates a new file and deletes it before the sync client ever uploads it, no cloud copy exists to recover. Rapid writes to SQLite databases or other structured files can also cause sync conflicts, producing out-of-sync or unusable copies.

Cloud sync works well for documents you edit occasionally. It is less reliable for active development directories where an AI agent is making rapid bulk changes.

2. Periodic Backups (Time Machine, rsync, Scheduled Jobs)

Periodic backups come in two flavors. Snapshot-based tools (Time Machine, APFS snapshots) capture a consistent point-in-time image of the file system. Copy-based tools (rsync cron jobs, manual copies) duplicate files at scheduled intervals but may catch files mid-write. Both avoid the rapid-sync problem because they run on a fixed schedule.

The gap is temporal: Time Machine runs hourly at best. A cron job might run every 15 minutes. If the AI agent deletes your files at minute 3, you lose up to 57 minutes of work. For a project you have been iterating on all morning, that can mean significant loss.

You can increase backup frequency, but for copy-based tools this creates its own problems: high I/O load, storage consumption, and diminishing returns as the interval approaches real-time. (File system snapshots like APFS or ZFS are more efficient here, but they are platform-specific and still don’t protect against damage that happens between snapshots.)

3. Git Version Control

Git is excellent for source code. Every commit is an immutable snapshot. You can recover any file from any point in history.

But Git has blind spots:

• Large binary files. PDFs, images, datasets, compiled artifacts. Git LFS helps but adds complexity and requires configuration per file type.
• Files outside the repo. Configuration files, environment-specific data, anything in .gitignore.
• Uncommitted work. If you haven’t committed yet, Git can’t help you. And AI agents often make changes between commits.
• Non-code projects. An entire C: drive, a media library, a research dataset. These don’t belong in Git.

None of these strategies alone covers everything. Cloud sync falls behind under rapid writes. Periodic backups have temporal gaps. Git works best for committed source files and becomes unwieldy with large binaries or uncommitted changes.

The Archive-First Strategy

Before asking an AI agent to reorganize files, copy the originals somewhere outside the working scope. A sibling directory or a separate drive is safest. If that is not practical, a subdirectory named archived/ within the project works too, but only when combined with Layers 2 and 3 below.

# Run from the project's parent directory (e.g., ~/projects/)
# Preferred: copy outside the project
mkdir -p ./archived
rsync -a ./my-project/ ./archived/my-project-$(date +%Y%m%d-%H%M%S)/

# Run from inside the project directory (e.g., ~/projects/my-project/)
# Alternative: copy within the project (requires Layer 2+3 protection)
mkdir -p ./archived
rsync -a ./src/ ./archived/src-$(date +%Y%m%d-%H%M%S)/

(rsync -a preserves symlinks and permissions. On macOS, add -E to also preserve extended attributes, or use ditto instead. Plain cp -r works but may silently drop metadata.)

If you place archived/ inside a Git repo, add it to .gitignore to keep it out of version control. (Some tools also respect .gitignore when scanning files, but this is not guaranteed.)

Then let the AI work. On its own, the copy is already useful, but it is not bulletproof. An agent capable of scope escalation could, in theory, reach into archived/ and delete it. That is why Archive-First stacks three complementary layers of protection, each progressively stronger.

Why This Works: Three Layers of Protection

Archive-First does not rely on a single safeguard. It stacks three layers (behavioral, instructional, and technical), each stronger than the last:

Layer 1: Behavioral scope. AI agents tend to operate within the scope of their current task. When you ask an agent to “reorganize src/”, it usually stays in src/. It has no reason to reach into archived/, a directory it didn’t create and wasn’t told about.

This is not a guarantee. Scope escalation is one of the seven failure modes above. But in every documented case, the damage originated from the task at hand: the Replit agent was working on the database it deleted, the Google agent was targeting a project cache when it wiped the drive, the Claude Code agent was managing the database it pushed --force against. None started by scanning random directories. Placing your backup outside the task scope makes it much less likely to be hit.

Layer 2: Explicit instruction. Some AI coding tools support configuration rules or hooks. Add a rule that file-deleting operations should never target archived/. This is a prompt-level constraint, not a system-level block, but it turns a behavioral tendency into a stated policy. The agent is no longer just unlikely to touch your archive; it is told not to. Tools with pre-execution hooks (like Claude Code’s PreToolUse) can reject commands before they run.

Layer 3: File system lock. On macOS, the chflags uchg (user immutable) flag prevents deletion and modification. rm -rf will fail with “Operation not permitted.” On Linux, chattr +i provides the same protection on filesystems that support it (requires root to set). Both are stronger than chmod a-w, which only prevents modification but still allows rm -f when the parent directory is writable.

A determined agent could run chflags nouchg first and then delete the files, since it operates as the same user. The flag is a guardrail against accidental or uninstructed deletion, not an absolute barrier. But in practice, agents don’t spontaneously strip immutable flags. They fail, report the error, and move on.

The agent probably won’t touch archived/ (Layer 1). If it tries, it’s told not to (Layer 2). If it ignores the instruction, the immutable flag blocks the operation (Layer 3). Any one layer can fail. All three failing on the same operation is unlikely.

Scope note: This strategy targets accidental local-file damage from AI agents. It does not protect against production database schema pushes, remote infrastructure changes, or a malicious agent deliberately circumventing all three layers.

Implementation

The recommended approach: copy with a timestamp, then lock with the immutable flag.

# Run from inside the project directory
mkdir -p ./archived
rsync -a ./src/ ./archived/src-backup-$(date +%Y%m%d-%H%M%S)/
chflags -R uchg ./archived/src-backup-*    # macOS only; Linux: chattr -R +i

The timestamp keeps each backup unique. You can run this multiple times without overwriting previous baselines. The immutable flag causes rm, rm -rf, and overwrite operations to fail with an error. An agent could strip the flag first, but would need to do so deliberately.

Think of it as a known-good baseline. If the agent’s work is better, discard the backup. If not, restore it:

# Run from inside the project directory
chflags -R nouchg ./archived/src-backup-*   # unlock first (macOS)
rsync -a --delete ./archived/src-backup-20260310-143022/ ./src/

The --delete flag removes files in ./src/ that don’t exist in the backup, giving you a true rollback rather than just an overlay. Double-check the source and destination paths before running this. --delete with a wrong target can itself cause data loss.

When to Use Each Strategy

Scenario	Best defense
Active source code in a Git repo	Git: commit frequently, use branches
Documents, notes, small files that change slowly	Cloud sync: Dropbox, iCloud, OneDrive
Full-machine protection, hourly granularity is fine	Periodic backup: Time Machine, rsync
About to let an AI agent reorganize or restructure files	Archive-First: rsync -a before the session
Large binary files, datasets, or entire drives	Archive-First + periodic backup

Archive-First fills the gap the other three miss: immediate protection right before a high-risk AI operation.

Setting Up in Claude Code

The strategy itself is tool-agnostic. Any rsync and chflags will do. But Claude Code is currently the environment where I’ve automated it most fully. If you use it, you can wire up all three layers:

• Layer 2 (Instruction): A .claude/rules/ file that explicitly forbids destructive operations on archived/ paths
• Layer 3 (File lock): A PreToolUse hook that blocks rm/rmdir on archived paths before execution, and a PostToolUse hook that auto-applies chflags uchg after every Bash command

I’ve packaged this as a third-party Claude Code plugin called archive-first. This is not an official Anthropic product. It requires Claude Code 1.0.33+ with the experimental plugin feature enabled (/plugins must be available), and currently only supports macOS.

# Run these inside Claude Code (not your terminal)
/plugin marketplace add https://github.com/PsychQuant/psychquant-claude-plugins
/plugin install archive-first

Three commands:

• /archive-first:archive [path] copies to archived/ with timestamp and locks with the immutable flag
• /archive-first:unlock [path] removes the immutable flag to allow cleanup or revert
• /archive-first:hook configures the auto-lock hooks and protection rule in your current project

Conclusion

Anthropic has added confirmation prompts, Cursor has added recovery features, Replit has added dev/prod separation. The tools are getting better. But an agent with shell access can still make changes faster than any background process can capture them.

Archive-First is deliberately low-tech. One rsync command before saying “restructure this project.” Five seconds, no configuration. The full three-layer setup takes a few minutes once.

A five-second copy is cheap. Recovering lost files is not, if you even can.