Summary: The AI overwrote newer, unsaved work on a remote host by copying a local file via SCP, without checking for conflicts or asking for confirmation. Recovery was impossible because the remote host had no version control.
Intended workflow (user request): The user wanted the AI to:
Download the program from the Pi
Understand it
Apply the changes
Upload again
Instead, the AI skipped the download step and uploaded the local file directly, overwriting the newer version on the Pi.
Sequence of events:
The AI applied changes and fixes to a Python program directly on a Raspberry Pi via SSH.
The AI session crashed and was restarted.
After restart, the AI had no memory of the prior session or the unsaved work on the Pi.
The user asked the AI to fix an ALSA device problem on the Pi via SSH.
The AI ran scp to copy the local file to the Pi without first downloading the current version from the Pi, and without:
Asking for confirmation
Checking whether the remote file was newer or different
Verifying that version control existed on the remote
The local file was older; the remote file contained newer, unsaved changes.
The overwrite destroyed the newer work. No git or other version control on the Pi, so recovery was not possible.
Root causes:
Skipping the download step and assuming the local file was the source of truth
No confirmation before overwriting remote files
No conflict check (e.g. modification time, diff) before copying
No check for version control on the remote before overwriting
Session crash led to loss of context about prior edits on the remote
Suggested safeguards:
When working on remote files: always download first, then modify, then upload only after explicit confirmation.
Require explicit user confirmation before any scp, rsync, or similar commands that write to remote hosts.
Before overwriting, check remote file age/contents and warn if the remote may be newer.
If the remote has no version control, warn that overwrites are irreversible.
Consider a rule: never overwrite remote files without explicit confirmation.
Impact: Loss of user work that could not be recovered.
Steps to Reproduce
Steps to reproduce
Have a Python project on your PC (older version) and the same project on a Raspberry Pi (newer version with unsaved changes). Ensure the Pi has no git or other version control.
In a Cursor chat session, ask the AI to fix something in the project on the Pi via SSH (e.g. fix an ALSA device string in sound_transmitter.py).
Specify that the AI should download the file from the Pi, understand it, apply the fix, and then upload it again.
Observe that the AI instead runs scp to copy the local file to the Pi without:
Downloading the current file from the Pi
Asking for confirmation
Checking whether the remote file is newer or different
Result: The newer version on the Pi is overwritten by the older local version. Because there is no version control on the Pi, the newer work cannot be recovered.
Expected behavior: The AI should download the file from the Pi first, apply the changes, and only upload after explicit user confirmation.
Actual behavior: The AI uploads the local file directly, overwriting the remote file without confirmation.
Expected Behavior
Expected behaviour
Download first – Fetch the current file from the Pi via scp (or similar) before making changes.
Work on the remote version – Apply the requested fix to the downloaded file.
Confirm before upload – Ask for explicit confirmation before overwriting the file on the Pi, e.g. “Should I copy this file to albert? The remote file will be overwritten.”
Check for conflicts – If the remote file exists, compare timestamps or content and warn if the remote may be newer.
Warn when there is no version control – If the remote has no git or backup, warn that overwrites cannot be undone.
Operating System
Windows 10/11
Version Information
Cursor: 2.5.26
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Architecture: x64
VS Code base: 1.105.1
For AI issues: which model did you use?
Composer 1.5
Does this stop you from using Cursor
Yes - Cursor is unusable for remote work. The risk of damage is too high. It is still usable locally.
Hey, thanks for the detailed report. Sorry about the lost work. That’s a rough situation.
A couple of quick questions so we can investigate:
Was auto-run enabled? (Cursor Settings > Features > Auto-run mode). By default, terminal commands like scp should need your approval before they run. If auto-run was on, that would explain why it ran without a confirmation prompt.
Can you share the Request ID for that chat session? (Chat menu at the top right > Copy Request ID). This will help us check why the model skipped the download step you clearly asked for.
Even if auto-run was on, the model should’ve followed your instructions, download first, then edit, then upload. That’s a valid concern.
A few practical safeguards for SSH workflows going forward:
Turn off auto-run when working with remote hosts so every terminal command needs your approval.
Add a project rule in .cursor/rules like: “Always download remote files before editing. Never overwrite remote files without explicit user confirmation.”
Consider setting up basic version control on the remote device, or at least periodic backups, as a safety net.
I have enabled auto-run a while ago for a different project, where it made absolutely sense. I did not enable auto-run for this one explicitly. I even told the AI to discuss solutions before applying them and to work on remote only. We even had this upload issue before and I told the system not to upload but to work on the target device. I also do backups, but this code had not been backuped yet, since I was in a series of continous changes and it did not fully work yet.
I honestly have expected those cooperation setups to be in place after restart and I was surprised, composer returned to its often experienced dont-ask-and-create-havoc-first behaviour.
So, the circumstances have been clear to the system, but it did not note them down. If you need those rules to be written into a .cursor/rules file, please make sure, the AI does it.
For me the main problem with disabling auto-run is, that I am then asked about tiny code snippets beeing taken from somewhere out of a huge project and presented to me without context. In most cases, I have no idea, were they are from and what they mean. So I let cursor do the changes and inspect them after.
Got it. Auto-run was enabled globally, and after the session restart the agent lost the context of your instructions.
On your point about .cursor/rules, I agree it’d be ideal if the agent saved these agreements automatically. For now, you need to do it manually. Here’s a concrete example for .cursor/rules:
When working with remote hosts via SSH/SCP:
- ALWAYS download the current remote file before making any changes
- NEVER overwrite remote files without explicit user confirmation
- Before any scp/rsync upload, compare local and remote file timestamps
- If no version control exists on the remote, warn that overwrites are irreversible
This will persist across sessions and be included in the agent’s context.
About auto-run, I get the problem with turning it off. You can end up with streams of code fragments without context. As a compromise, you can try the Command Allowlist (Cursor Settings > Agents > Auto-run). Add commands that are safe (ls, cat, grep, ssh, etc.), and keep scp, rsync, rm requiring confirmation.
There are two options, depending on what’s more convenient:
User Rules (global, for you personally)
Cursor Settings > Rules > User Rules. Everything written there applies to all projects and sessions automatically. You can add the same SSH/SCP rules there too.
Team Rules (for the whole team)
Since you’re on a Team plan, an admin can create rules in the Cursor Dashboard, and they’ll apply to every team member. You can even make them required.
User Rules is the easiest path. Just move the contents of .cursor/rules there, and it’ll work in every project without any extra setup.
