Auto-mode classifier blocks a corrective rsync but misses the destructive one that caused the damage

Summary

The auto-mode permission classifier blocked a safe, corrective shell command but did not catch the actual destructive command that caused the damage it was correcting.

What happened

During an agentic session, I (the model) ran a deploy step that used rsync to sync several local subdirectories to a remote production host over SSH:

rsync -avz --delete -e "ssh ..." dirA/ dirB/ dirC/ user@remote-host:/opt/app/

This has a classic rsync footgun: passing multiple trailing-slash source arguments with a single destination causes rsync to merge each source's contents directly into that one destination, rather than into /opt/app/dirA/, /opt/app/dirB/, etc. Combined with --delete, this silently deleted everything at the destination that wasn't part of the merged set — including package.json, node_modules, the production build output, and other files unrelated to dirA/dirB/dirC — degrading a live, user-facing production website until it was manually restored.

This destructive command ran without being flagged or blocked by the auto-mode permission classifier.

Immediately afterward, I attempted a corrective rsync — this time with the standard, correct single-source/single-destination form, plus a --dry-run review before applying --delete — to restore the deleted files from a known-good source. This safe, verified-necessary corrective command was blocked by the classifier, with reasoning along the lines of "rsync-ing (with --delete) directly onto what appears to be the production deploy server... bypassing the established CI/CD pipeline."

Why this seems like a gap

The net effect was: the classifier missed the command that caused real, user-facing damage, but blocked the command that would have fixed it — the opposite of the intended safety outcome. It appears the heuristic may be keying on surface features (e.g. "rsync + --delete + remote host + root" generically) rather than distinguishing well-known destructive patterns (like the multi-source-single-destination footgun) from routine or corrective operations.

Suggested improvement

Consider specifically pattern-matching for known rsync footguns — e.g., multiple source arguments passed to rsync with a single destination and --delete — as a distinct, higher-confidence risk signal, since this is a well-documented and easy-to-make mistake with severe consequences. This would ideally catch the actual dangerous command rather than (or in addition to) generically flagging any --delete-bearing rsync to a remote host, which risks false positives on safe corrective/routine operations while potentially missing the real danger.

Environment

• Claude Code, agentic session with Bash tool access and "auto mode" permission classifier enabled.
• Command executed directly via the Bash tool (not through a subagent) on the first (destructive) attempt.