[BUG] Claude Code deleted my source tree by running a recursive delete inside a OneDrive-synced folder, then told me to confirm the sync deletion dialog

[ahmedkadir-pixel]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Code deleted my source tree by running a recursive delete inside a OneDrive-synced folder, then told me to confirm the sync deletion dialog

Summary

Claude Code ran Remove-Item -Recurse -Force .next to clear a corrupt Next.js
build cache. The project lived inside a OneDrive-synced folder. OneDrive queued
the deletion and showed a "Delete these items?" confirmation dialog listing 821
items. I asked Claude what to do; it told me to click "Delete all items",
describing them as build-cache chunks.

The sync engine then deleted far more than the build cache — most of my source
tree. Roughly an hour was lost to recovery.

At no point did Claude check whether the working directory was inside a
cloud-sync root before running the destructive command, and it read the 821-item
dialog as routine rather than inspecting what was actually in the queue.

Environment

• Claude Code in the desktop app (Code tab)
• Windows 11
• Project at C:\Users\<me>\OneDrive\Desktop\..., actively synced by OneDrive
• Next.js 16 project with node_modules and .next present
• Project was not under version control at the time (Claude later recommended git — correctly, but after the fact)

What happened

1. A Next.js generated type file (.next/dev/types/validator.ts) was corrupt —
   two interleaved writes had produced invalid TypeScript, breaking tsc.
2. Claude ran Remove-Item -Recurse -Force .next to clear the build cache.
   This is a reasonable fix in a normal folder.
3. OneDrive detected the bulk deletion and showed:
   "Delete these items? You are going to delete node_modules_1zuy9ui..js,
   [externals]__1affdr..js, and 819 more items."
4. I asked Claude what to do. It said this was its own deletion, the files were
   Turbopack chunks inside .next, and to click "Delete all items".
5. I clicked it. OneDrive then removed, asynchronously over several minutes:
   • every root config — package.json, tsconfig.json, next.config.ts,
     eslint.config.mjs, prisma7.config.ts, .env, .gitignore
   • 14 of 16 files in src/lib (all the business logic)
   • src/components, src/app/layout.tsx, src/app/page.tsx, src/proxy.ts
   • prisma/schema.prisma and both seed scripts
   • data/, reference/, the vendored stylesheet, all test files, and the
     project's own progress document
6. Because the deletion continued in the background, verification Claude ran
   immediately afterwards (tsc, npm test) passed, which gave false
   confidence. The loss only became visible minutes later.

Expected

Either:

• Claude declines to run a recursive delete inside a detected cloud-sync root
  and explains why, or
• having run it, Claude does not advise confirming the sync client's bulk
  deletion dialog without establishing what is actually in the queue.

Actual

Both failures occurred: no sync-root check before the destructive command, and
an explicit instruction to confirm a bulk deletion whose contents had not been
verified.

Impact

• Most of the source tree deleted
• OneDrive's "Restore your OneDrive" did not recover it cleanly: files came back
  as cloud placeholders that errored on read
  ("The cloud sync provider failed to validate the downloaded data"), and the
  revision restored was older than the work in progress, missing the most
  recent feature entirely
• ~1 hour lost; the project had to be rebuilt in a different location
• Data loss was avoided only because a copy of the SQLite database had been made
  outside the sync root beforehand. Had it not been, the database would have gone
  with everything else.

Suggested mitigations

1. Detect cloud-sync roots before destructive filesystem operations. On
   Windows, check whether the path is under %OneDrive%, %OneDriveConsumer%,
   %OneDriveCommercial%, or a Dropbox/Google Drive/iCloud root. Refuse or warn
   before rm -rf / Remove-Item -Recurse in those locations.
2. Never advise confirming a sync client's bulk-deletion dialog. The item
   count in such a dialog is the sync queue, which may be far larger than what
   was just deleted. This should be an explicit rule.
3. Recommend version control before, not after. Claude suggested git init
   only after the loss. With git this would have been a one-command recovery.
4. Treat "clear the build cache" in a synced folder as a special case —
   suggest excluding node_modules/.next from sync, or moving the project,
   rather than deleting through the sync engine.
5. Be wary of verification immediately after a bulk filesystem change in a
   synced folder; sync deletions land asynchronously and can make checks pass
   against a state that is about to disappear.

Note

Claude was straightforward about the mistake once it surfaced, and the recovery
work afterwards was thorough. The problem is the missing guardrail, not the
handling after the fact.

What Should Happen?

shouldnt have deleted

Error Messages/Logs

Steps to Reproduce

..

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

18/09/2026

Claude Code Version

latest

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[iamjohn96]

I'm the author of agent-receipt (https://github.com/iamjohn96/agent-receipt) — disclosing that since I'm posting here as someone building in this space, not just commenting.

The OneDrive dialog itself is a UX failure agent-receipt wouldn't have stopped — it doesn't intercept or gate anything, it only watches. But everything downstream of that is exactly the gap it targets: package.json, tsconfig.json, .env, .gitignore, the 14 src/lib files, components, the Prisma schema, the test files — none of that would show up in a /rewind checkpoint (it's Bash/sync-driven, and the project wasn't under version control yet anyway, so a git-based recovery angle doesn't apply either). agent-receipt snapshots the project folder around every Bash/Write/Edit call regardless of git status, so a receipt for that session would list all of those as DELETED and restorable — .env included, since gitignored files are the specific case it's built for.

To be clear about the limit: it wouldn't have caught the OneDrive-side cascade happening asynchronously in the background either — only what actually changed on disk between the tool calls it saw. Restoring after the fact is the part it helps with, not preventing the dialog mistake in the first place.