Agent and model consistently misunderstand concept of "moving" code/files

[jrista]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s agent seems to have a SIGNIFICANT problem understanding the concept of “move.” It is my general preference that existing code, if it needs to be somewhere else, that it is MOVED, or even copied and pasted, as is, without modification.

However, when I give even simple prompts to move code or move a file, the agent ALWAYS seems to resort to generating an entirely new file, often quite different in terms of contents, from the original, then deleting the original. This is a HORRIBLE practice!! It is dangerous, often quite destructive (especially when talking about uncommitted files in git), and should not be the default mode of operation for the agent.

When the user requests that code or a file be MOVED, it should be moved. As in, the original contents, copied and pasted exactly as-is, without change, into a new location…or if its a file, the file should literally be moved. When in a git repository, a file move, if it has been previously committed, should be moved with git mv to preserve file history, and if it is an uncommitted file then the file should be moved with the standard mv command.

The primary concern here is that, when the agent+llm REGENERATE a file/code, its a NEW file/NEW code, in the destination location, and due to the probablistic, non-deterministic nature of LLMs, the recreation is never the same as the original.

Non-determinism in models, is a critical factor that should be avoided in certain operatoins at all costs. MOVING code, files, heck any content not necessarily even code (i.e. documentation, regular text content) is one of the things that should really be done in as strictly a DETERMINISTIC manner as possible. Arbitrarily rewriting code or other content, files, etc. that have already been vetted, verified and tested, is a terrible practice in general, however it seems to be the fundamental modus operandi for Cursor (and other agentic and LLM powered coding tools).

I think for tools like Cursor to be truly viable in the long term, they need to start acquiring capabilities to perform certain key operations as deterministically as possible. Moving code/content/files is a critical one. (Refactoring is another, and I think I have another bug report or perhaps feature request about that.)

Steps to Reproduce

Request the agent move a file, or a specific set of code (i.e. line selection) to some other location.
Weep as the code you are purposely trying to PRESERVE is detroyed when the agent instead, CREATES a new file, generates arbitrarily different content (even if it sorta does the same job/serves the same purpose), then DELETES your original!!!

Expected Behavior

When file/code/other content is asked to be MOVED, it should be MOVED. NOT regenerated differently and the original nuked (often irrecoverably!)

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.4.5 (Universal)
VSCode Version: 1.99.3
Commit: af58d92614edb1f72bdd756615d131bf8dfa5290
Date: 2025-08-13T02:08:56.371Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

[jrista]

Some additional remarks here. Once the agent has already started the whole horrible process of “I’ll create a NEW file in the destination, have the llm populate it with arbitrarily generated new content, then delete the original!” If you try to correct it, the agent/model seem totally incapable of grasping the concept. Even if you provide clear instructions, about removing the NEWLY GENERATED file, the agent and model seem insistent then on removing the ORIGINAL, and keeping their NEW file. I almost lost a critical script here, because it tried to run git rm on it (which, for some reason, jsut ran, even though, and I’ve verified this, it is NOT in my allow list!) The only reason it didn’t nuke my file, is the darn agent had the path wrong. Thankfully!!

I stopped it right then, but the command had already executed before I could hit stop.

I am honestly rather baffled by the INSISTENCE the agent and model have in these cases. I’ve gone round and round with them at times (after taking measures to preserve/back up the content I needed preserved, just in case), and they just DO NOT seem to grasp this concept properly.

The EXPRESS INTENT of moving something, is PRESERVATION. With software projects, once you have invested the time, effort and money on making sure that code, or anything (scripts, tests, documentation, whatever) is good, correct, viable, etc. then that content, unless an explicit, specific need arises to change it, should NEVER be changed! To change it arbitrarily (the issue at hand here, the apparent DEFAULT MODE of agentic IDEs and LLMs), is to destroy all the effort that went into vetting that code in the first place.

Now, I understand that there is the whole vibe coding concept, and that vibe coders may have a different opinion here. At least, now (I quite suspect many opinions will change in the future when they have suffered from arbitrary change enough to destroy their products and reputations…) I don’t know if I would be called a vibe coder, or just an agentically powered programmer, or what…but, I DO care about the code that is generated, even if it is not always generated by my own two hands. I also still do care that VETTED aspects of my projects, maintain a very necessary aspect of durability and stability, until there is an explicit need for any of that content to change: a bug is reported; an explicit feature refactor is required; functional requirements change dictating refactor; etc.

Without an explicit need to change, a requirement, then vetted code and other content should never be arbitrarily changed. Hence the specificity of…moving….or, my prior request about having deterministic refactoring tools, that the agent+llm could invoke (much like they can read, grep, edit files, etc.) to perform certain kinds of operations that SHOULD, and need to be, strictly deterministic (even a simple identifier rename with an LLM, can be quite troublesome and problematic due to the non-deterministic nature of the model!)

Anyway. I’ve run into this issue a few dozen times now, and it seems there is a very non-trivial misunderstanding by agent and model, when MOVES are requested, and the default approach by agent and model is to generate (arbitrary) new, nuke old. Which is really bad!