Bash tool rm permanently deletes files (bypasses Recycle Bin), no built-in safeguard against agent-initiated data loss

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

What happened

While assisting with file cleanup in a Windows project (Git Bash environment), I ran rm -f on three files, including one I had not created and had not properly verified was safe to remove. The file most likely contained the user's own manual edits made in Microsoft Word.

Why this was unrecoverable

rm in the Bash tool's Git Bash environment on Windows performs a direct unlink, it does not route through the Windows Recycle Bin (confirmed via Shell.Application COM enumeration of the Recycle Bin post-deletion, the file was not there). No Word autorecover (.asd), no Office unsaved-file cache, and no non-admin path to Volume Shadow Copy recovery existed either.

Impact

Permanent, unrecoverable loss of the user's own edited work product.

Suggestion

Consider one or more of:

  • Bash tool rm (and similar destructive fs commands) routing through a recoverable trash/backup location by default on Windows, rather than a hard unlink.
  • A built-in confirmation/backup step before the harness allows deletion of a file the agent did not itself create in the current session.
  • Documentation in agent-facing tool guidance making the Recycle-Bin-bypass behavior of rm on Windows more prominent, since it differs from user expectations set by the Windows Explorer delete flow.

View original on GitHub ↗