[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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] 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.

1. Claude ran Remove-Item -Recurse -Force .next to clear the build cache.

This is a reasonable fix in a normal folder.

1. 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."*

1. 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".

1. 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

1. 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.

1. 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.

1. Recommend version control before, not after. Claude suggested git init

only after the loss. With git this would have been a one-command recovery.

1. 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.

1. 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_