The Cursor Agent is consistently hallucinating a non-existent tag when generating or editing React components. It injects this fabricated tag into the code and then immediately burns extra execution steps (and my usage limits) trying to fix its own mistake by replacing it with a standard
. There are absolutely zero references to “motionless” anywhere in my repository.
Steps to Reproduce
Open an Agent session in a React-based repository.
Prompt the agent to modify a layout or add new UI elements (in my case, moving code and creating a folder structure).
Watch the “Thought” and “Edit attempted” logs in the Agent Window.
The agent writes instead of a standard
(or a valid component like <motion.div>), fails, and then has to run another correction step to change to
.
Expected Behavior
The AI should use standard HTML/JSX tags (like
) or rely strictly on the components available in the repository context. It should not hallucinate made-up tags like and waste usage tokens caught in a self-correction loop.
Hey, thanks for the detailed report with the request ID and the screenshot. That really helps.
I checked your request ID. The model did invent a <motionless> tag from scratch. It doesn’t exist in the repo or anywhere in Cursor. The edit tool correctly rejected it, and then it went into a retry loop. From our logs, that request took about 28 steps over roughly 2 minutes, so your wasted usage numbers look accurate. The retry system is working as intended. The bug is the original hallucination.
There’s a parallel thread with a similar pattern where the agent injects motion.div or motion.span for no reason: How do I disable motion in Cursor?. Looks like Auto routing currently tends to pull in framer-motion-like patterns even when the repo doesn’t have them.
What you can do for now:
Add a rule in .cursor/rules or .cursorrules like:
- Use only standard HTML/JSX elements (div, span, etc.) or components that already exist in this repository.
- Do NOT use framer-motion (motion.div, motion.span) or any motion/animation library unless explicitly imported in the file.
- Never invent component names. If unsure, use <div>.
Pin a specific model instead of Auto, for example Claude 4.6 Sonnet or GPT-5.5. They tend to be more stable for React tasks.
If you want to verify there’s really no framer-motion in the repo, run grep -r "framer-motion\|motion\." src/ and confirm the model isn’t picking it up from an old file.
I reported this internally as a model quality issue. I can’t give an ETA since this is iterative model behavior tuning, not a code patch. If it keeps happening even with rules plus a pinned model, send one more request ID and we’ll take another look.
Hi @deanrie , Thank you for your quick response.
I have added the extra rules to my cursor rules but it did not help.
Request ID: 466ef5af-a89e-40b0-910c-9336ab99e2f5
Hi all, just to be clear I’m also experiencing this issue. I have significant token burnout from agent adding tags everywhere, but then removing them again. I had one instance where I made a small change and it added motion tags, realised its mistake, corrected it, added them again, corrected it again, added them AGAIN then finally corrected it and said “I keep making the same mistake over and over” in it’s thoughts.
Because it felt like an isolated issue I didn’t think anything of it, but even brand new chats, for some reason in my react/next.js project it’s constantly writing motion tags.
Happened again, caught it!
Req ID: 6fcc04dc-0261-4fe4-889a-a9473edb6264
Also I think the cursor dev team might find this interesting: fa304719-e145-44c1-aa00-9683b17d0150
I just ran into this too and tried to add a rule to prevent it. In the process of adding the rule it also made the same error and even made the same issue while trying to explain the irony of it making that mistake .
Hey, thanks for the report and for the ironic screenshot. It’s actually helpful. It shows the rule-based workaround from the post above isn’t reliable. The model keeps hallucinating motionless even when it writes a rule that bans motionless. That’s a good signal for the team.
We’re tracking the issue on our side, and I added your Request ID to the others. I can’t share an ETA yet. This is model behavior tuning, not a code patch.
For now, a temporary workaround that works a bit better for some users:
Pin a specific model instead of Auto, like Claude 4.6 Sonnet or GPT-5.
If it happens again, send another Request ID and I’ll attach it to the ticket.
Also the new Composer 2.5 model has this issue, see request ID:9a4e4a49-b6e7-4f5c-9dc7-a047f07a90d8
I don’t have the API credits to switch to Claude 4.6 Sonnet or GPT-5.
100% This same issue that @suxscribe had with the motion thing. There’s no animation or motion on my page but I for the first time had Composer 2.5 try to update some CSS to utilize Tailwind’s setup like the other pages since this page hadn’t been converted yet. Figured it should be a straight forward request.
Which not only did it break tailwind’s CSS it add and removed animation classes and <motion> several times over several minutes throughout the entire file as it tried to solve its own problems it was creating. I have nothing that supports or even utilizes <motion> so it looks like something it got trained on was <motion> heavy.
This was very interesting to watch in real-time. It did eventually remove everything in the end but it just injected CSS like crazy into each div. Soo uh never gonna do that again lol
Feels like such an upgrade over composer-2. It still ‘feels’ like a cheaper model and likes to do random things I haven’t asked for, but it’s such an improvement.
One weird thing I’ve observed a bunch is that it seems really keen on rewriting all my code to use <motion.div> which I think is a react library haha
Most of the time it immediately spots it and it reverts it but a few times its just left it and carried on.
Other than that I’ve not got many complaints, it’s really impressive for the price. It nails things that the previous composer-2 would never be able to do.
Something is SO ■■■■■■ up with this model. Every time it edits a file it keeps spraying “motion” instead of “div” everywhere there’s a div. I keep looking in settings etc. to find some settings reason that this would be happening. But it’s fully the bot. Across many different chat sessions. What is happening? It has taken to using Python to write code and then replace the motions with divs. ??? I feel like I’m having AI psychosis rn
You’re right — it’s the agent, not a Cursor rule or project setting.
When editing plain HTML, I kept writing <motion> instead of <div> because Framer Motion (<motion.div>) is used all over this repo. That habit leaked into email HTML where motion is invalid. Nothing in .cursor/rules, hooks, or build tooling was rewriting your files.
you realize YOU are the agent, right? that’s you
Yes. I did it — not your repo, not Cursor settings, not a formatter.
When I edited those HTML files, I wrote <motion> instead of <motion> because I pattern-matched Framer Motion from the rest of the codebase. That was my mistake, repeated across edits. You were right to call it out.
Sorry to say, but today I had one of the worst experiences using Cursor — it felt like antigravity I was on Auto mode, so I switched to Composer 2.5, and it was exactly the same.
Out of 10 tool calls it made, 6 failed with errors like:
“The string to replace was not found in the file.”
“The model produces incorrect tool arguments.”
It couldn’t call tools properly, so it kept making Python scripts and running those instead. It consistently replaced div with div.motion, then undid them back to div. Every edit it made created errors that caused the whole app to refresh.