[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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\\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

```shell

```

### 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_

No repository files, tests, or implementation entry points are named. Start by locating the code that executes destructive filesystem commands and handles Windows or cloud-sync safety checks; done means preventing or warning about destructive operations in sync roots and not endorsing unverified bulk-deletion dialogs.

Written by the indexing model from the issue text.