[Bug] Sonnet 5 deletes entire folder contents while attempting file enumeration

The detail that makes this the most interesting report in this class, it was counting files.

Not deleting, not cleaning up, not migrating. Enumerating. Which means there was no bad intent to catch. In the other data loss reports here the command was mislabeled, so in principle a better label could have saved it. Here the label would have been correct. "I am counting the files in this folder" is a true statement about what the agent was trying to do, and the folder is gone anyway.

That is the part worth sitting with. Any check that reasons about what an operation is for passes this straight through, because the purpose was genuinely benign. The only thing left to inspect is what the command will actually do to the filesystem, computed rather than inferred.

I think two things that would sharpen the report if you still have the transcript:

1. The exact command. On Windows the two usual suspects look nothing alike. A Remove-Item -Recurse emitted where Get-ChildItem was meant is a model error. A rmdir /s /q whose path collapsed because of nested quoting between cmd and PowerShell is a shell interop error. There is a well documented run of the second kind hitting Windows users of other agents, where the quoting degrades the target all the way down to a drive root. If that is what happened here too then it is not really a Sonnet 5 problem, it is a shell interop problem that every agent on Windows is going to keep hitting.

1. Worth stating explicitly in the report: recursive deletes on Windows do not go to the Recycle Bin. So the usual first response, go check the bin, does not apply here, and the loss is immediate and total. That is a large part of why this class of failure is so much worse on Windows than on macOS or Linux, and it is the kind of thing that gets missed when the issue is triaged by someone on a Mac.

(Full disclosure on why I'm asking, I'm building a pre-execution hook for this class of failure, and which of the two it is genuinely changes what the fix looks like. If it stayed inside the target folder, capturing it beforehand is cheap and the loss is undoable. If the path collapsed to a drive root, nothing captures that in time and the only honest move is to refuse the line and show you the expanded path first. I'd rather ask than assume.)

Sorry about the folder.

The exact command is in the screenshot.
And it's not only recursive deletes that don't go to the recycle bin.
Files only go to the recycle bin if they're deleted from Windows' Explorer.
No deletions performed by a CLI util will go to the recycle bin.

I'm sorry, I had that wrong.

The bit I keep coming back to is that the agent says it ran that command just to check the file count. It wanted the files matching Reports/report_*. It deleted the files matching Reports/report_*. Same glob. If anything had expanded it and printed the list, the agent would have had its count, and nobody could have approved that delete by accident. One operation, both jobs.

I build a pre-execution hook for exactly this, so I ran your command through it. It escalated instead of capturing, and the reason is a bit embarrassing: it never expanded the glob either. os.path.exists("Reports/report_*.txt") is false, so it saw zero files rather than too many. Same blindness as the agent, one layer up.

Fixed now. It expands the glob, prints the list of files the command is about to cost you, snapshots the folder, and undo puts it all back. Tested on your exact command.

Happy to send it over if you want to poke at it. Sorry about the report files.

Don't worry about the files. I got most of them back using Recuva.
About your explanation, I guess it's a bit over my head, but glad if it helped any.
Are you with Anthropic?

No. Just some guy who builds a hook that tries to catch this stuff
before it runs. Sorry for the wall of text, that was me thinking out loud
more than anything useful to you.

Glad Recuva got most of it back.