Don't stop here
Hand-picked guides our readers explore right after this one.
AI-powered code editor prompts for Composer, Chat, and inline editing
Read the guideStunning image generation with Midjourney prompt mastery
Read the guidePrompts for OpenAI Codex CLI coding agent for code generation, debugging, and multi-file projects
Read the guideYou ask for a one-line fix, click Apply, and Cursor replaces the entire file, often leaving only the function it was working on and deleting everything around it. This is one of the most reported problems on the Cursor forum, and it has two overlapping causes. The first is the model producing a full-file rewrite with placeholder comments instead of a targeted patch, which the apply step then takes literally. The second is the apply mechanism itself failing to match the edit against the existing file and falling back to replacing the whole thing. Neither is something you can configure away entirely, so the practical answer is a workflow that makes the failure survivable and rare: commit before you prompt, ask for diffs rather than files, keep the target scope small, and review the diff before accepting rather than after. If it has already happened, stop typing and recover from git or the editor's local history first, because both windows close fast.
A small requested change produces a diff with hundreds of deletions
The file is left containing only the function you asked about
Unrelated functions, imports, or comments disappear
The rewritten file contains placeholder comments like 'rest of the code here'
Apply lands the change in the wrong file entirely
Changes appear and then revert on specific files
When the response is a complete file rather than a targeted edit, the apply step writes exactly that, including any elision comments standing in for code it did not repeat. Everything those comments replaced is gone.
The edit tool locates the region to change by matching against existing content. When that match fails (after a recent change, in a file with repeated similar blocks, or with unusual formatting) it can fall back to replacing the file rather than erroring out.
In big files the model works from a partial or outdated view of the content. It reconstructs what it thinks the file contains, and the reconstruction drops whatever it did not see. Large files fail this way far more often than small ones.
In agent workflows, edits can be written before you look at them. The destructive change lands on disk first and you discover it afterwards, sometimes several steps later once further edits are stacked on top.
Prompts like 'clean this up' or 'refactor this file' authorize a rewrite. The model does what was asked, at a scope you did not intend, and the result is indistinguishable from a bug.
When to try: First, the moment you notice the damage
If the file is tracked and the change is uncommitted, run git diff to see what was lost and git checkout -- path/to/file to restore it. Do this before making further edits, since new changes make the recovery messier.
When to try: When the file is untracked or the change was already committed
In Cursor (built on VS Code), right click the file in Explorer and look for Local History, or open the Timeline view in the Explorer sidebar and restore an earlier entry. This works even for files never committed, but entries age out, so check straight away.
When to try: Always, before prompting
Make a commit (or at least git stash) before prompting for changes. This turns a catastrophic overwrite into a one-command undo. It is the single highest-value habit for working with any AI editor, and it takes two seconds.
When to try: Every edit request
Phrase requests as: 'Show only the changed lines as a diff. Do not output the full file. Do not remove or reorder anything I did not ask about.' Constraining the output format is the most reliable way to prevent a whole-file rewrite, because the model never produces the file that would overwrite yours.
When to try: For any change inside a large file
Select the exact function or block, then prompt with that selection as the target and say explicitly that changes must stay inside it. A narrow, named target removes the ambiguity that leads to broad rewrites.
When to try: Every single apply
Read the change count before clicking Accept. If a one-line request shows dozens of deletions, reject it and re-prompt with tighter constraints. Rejecting costs seconds, and accepting a bad rewrite can cost an afternoon.
When to try: Before using agent mode on real work
In Cursor's settings, disable auto-apply or auto-run for edits so changes require confirmation. Agent runs that write without review are where the worst damage happens, because several edits stack before you see any of them.
When to try: As a structural fix, after the second incident
Files of several thousand lines are the most common victims because the model cannot hold them accurately. Break them into modules, and add a project rules file instructing the assistant to make minimal, targeted edits and never output full files unless asked. Rules apply to every request and remove the need to repeat the constraint.
Commit or stash before every AI-assisted edit so recovery is one command
Ask for diffs and explicitly forbid full-file output
Read the deletion count in the diff before accepting any change
Keep files small enough that the assistant can see them completely
Report it on the Cursor community forum or through in-app feedback if Apply consistently replaces whole files on a specific file or project even with tightly scoped requests, or if edits land in a file you did not reference. Include the Cursor version, the model used, the file size, and the prompt. Include the request ID if the app offers one, since it lets the team trace the apply step directly.
Either the model returned a complete file rather than a targeted patch, and the apply step wrote it verbatim including any 'rest of code here' placeholders, or the apply step could not match the edit against your existing content and fell back to a full replacement. Large files and stale context make both far more likely.
Use git first: git diff shows what was lost and git checkout -- <file> restores it if the change is uncommitted. If the file is untracked, open the Timeline view in the Explorer sidebar or right click the file and check Local History, then restore an earlier version. Act quickly, before further edits pile up.
Constrain the output: ask for a diff of only the changed lines, forbid full-file output, name the exact function or block, and state that nothing else may be removed or reordered. Add the same constraints to a project rules file so they apply to every request automatically.
Both. There are long-standing forum reports of the apply step overwriting files even on well-scoped requests, so it is not purely user error. But open-ended prompts and very large files make it dramatically more likely, and diff-constrained prompting on smaller files reduces it substantially.
It can, because agent runs may write edits without waiting for your review, and several changes can stack before you see any of them. Disable auto-apply for real work, or run agents on a branch so the entire run can be discarded in one step if it goes wrong.
Product behavior and limits can change. These primary sources were used to verify this guide.