Hi @Joerg_Kunze,
Thank you for this incredibly thorough incident report. Priority is recovering your files and I’m going to help you through it
Recovery: Since git stash push -u records untracked files in the stash before removing them from disk, your credential files should still be recoverable. On the remote host, try:
git stash list
git stash apply
This will restore the stashed files (including the untracked ones). If it creates conflicts with the tracked files, you can extract just the untracked files from the stash using git show stash@{0}^3:<path/to/credential/file> > <path/to/credential/file>.
On the core issue: You’re right that the agent should have inspected the remote state and asked before running a command that deletes untracked files. This is a known concern — the team is tracking improvements to how agents handle destructive git commands, especially on remote hosts. Your report (and your earlier thread) adds valuable evidence for prioritizing this.
Workarounds for now:
- User Rules (Cursor Settings > Rules > User Rules) — add rules that persist across all projects and sessions:
When working with remote hosts via SSH:
- NEVER run git stash with -u or --include-untracked without explicit user confirmation
- NEVER run destructive git commands (git stash -u, git restore, git reset --hard, git clean) without first listing what will be affected and getting user approval
- ALWAYS inspect remote state before modifying it
- Command Allowlist (Cursor Settings > Agents > Auto-run) — this lets you keep auto-run enabled for safe commands (
ls,cat,grep,ssh) while requiring confirmation for dangerous ones. Any command not on the allowlist will prompt for approval.
I understand the frustration with auto-run being all-or-nothing. The Command Allowlist is the best middle ground right now — it avoids the “approve every tiny change” problem while still catching destructive commands.