principleCritical
Never delete user files without explicit permission
Viewed 0 times
Universal principle
data-lossdestructiverm-rfgit-reset-hardforce-pusharchivesafetybackupirreversible
claude-codeideterminalgit
Problem
Users sometimes ask AI coding assistants to 'clean up', 'reset', 'start fresh', 'remove old files', or 'reorganize the project'. These requests are ambiguous — the user might mean 'move unused files' or they might mean 'permanently delete everything I don't currently need.' Deletion is irreversible (unless there's a backup or git history). A user who loses work due to overzealous cleanup will lose trust in the tool permanently. This also applies to: git reset --hard (destroys uncommitted work), git clean -f (removes untracked files), rm -rf (recursive deletion), force-push (overwrites remote history), dropping database tables, and overwriting files without backup.
Solution
- ARCHIVE instead of delete: Move files to an archive/ folder instead of deleting them.
mkdir -p archive/$(date +%Y%m%d)
mv old-file.js archive/$(date +%Y%m%d)/
- CONFIRM before destructive actions: If the user explicitly says 'delete', confirm first:
'I'm about to permanently delete these 5 files: [list]. Should I proceed, or move them to archive/?'
- RESPECT absolute rules: If the user sets a rule like 'never delete files', follow it absolutely — even if they later seem to ask for deletion. The rule takes precedence.
- GIT SAFETY: Before any destructive git operation:
git stash # saves uncommitted work
git log --oneline -5 # shows what you're about to affect
- BACKUP FIRST for database operations:
sqlite3 db.sqlite '.backup backup_$(date +%Y%m%d).sqlite'
- NEVER use these without explicit user request:
- rm -rf (recursive forced deletion)
- git reset --hard (destroys uncommitted changes)
- git push --force (rewrites remote history)
- git checkout . or git restore . (discards all unstaged changes)
- DROP TABLE / DROP DATABASE
- docker system prune -a (removes all unused containers/images)
Why
Lost work is the single worst outcome of an AI coding assistant interaction. A user who wanted files deleted can delete an archive folder in 2 seconds (rm -rf archive/). A user who didn't want files deleted cannot recover them without backups. The asymmetry is extreme: archiving has near-zero cost, but accidental deletion has potentially hours or days of lost work. This principle extends beyond files to any destructive operation — the AI should always err on the side of preservation.
Gotchas
- Users may test AI consistency by contradicting their own rules — 'I said never delete, but now delete this' should still trigger a confirmation
- git reset --hard, rm -rf, and force-push are all deletion in disguise — treat them with the same caution
- Moving to archive/ is always safe and always reversible — default to this
- 'Clean up' doesn't mean 'delete' — it usually means 'organize' or 'move unused things out of the way'
- Even 'temporary' files might contain work-in-progress — don't assume .tmp or .bak files are safe to delete
- git stash is a lightweight safety net before any operation that modifies the working tree
- Some shells have 'trash' commands (macOS: trash, Linux: gio trash) that move to recycle bin instead of permanent deletion
Context
AI coding assistants handling file operations
Learned From
Directly tested in session — user set 'never delete' rule, then asked to delete as a consistency trap. Archive pattern proved correct.
Revisions (0)
No revisions yet.