Cursor keeps inserting motion.div, motion.span, etc., and then tries to fix it. Even setting custom rules doesn’t stop it! How can I completely disable this behavior?
Hey, this isn’t a Cursor setting. The model itself tends to reach for motion wrappers, which is a common pattern in modern Vue and React code via motion-v / @vueuse/motion / framer-motion. There’s no “Disable motion” checkbox, so the only levers are rules and model choice.
What to try:
Create .cursor/rules/no-motion.mdc with an explicit negative and alwaysApply: true:
---
alwaysApply: true
---
Do NOT use motion-v, @vueuse/motion, framer-motion, or any animation library.
Do NOT generate <motion.div>, <motion.span>, <motion.*> or import { motion }.
Use plain HTML/Vue elements. If animation is needed, use CSS transitions or @keyframes.
A strict negative plus specific package names works better than a generic “no motion”.
If the rules still get ignored, that’s a known issue with adherence for alwaysApply. There’s a thread here: `alwaysApply: true` rules are being completely ignored now. Also copy the same text into AGENTS.md in the project root, it sometimes works more reliably.
Switch from auto to a specific model, like Claude 4.6 Sonnet or GPT-5.4. Auto sometimes picks models with a stronger bias toward motion wrappers. Different models follow rules differently.
If the project is already messy, send the agent a separate message like: “Remove all motion-v / framer-motion / @vueuse/motion usage from the project and replace with plain elements”.
Let me know if the rules still don’t stick. If so, share your .mdc file contents and the Request ID, and we can dig into what’s going on.
This is def a prevalent issue with Auto/Composer… It spends a lot of time rewriting <div to <motion, and then back again… the team should look in to this
Yes… Moreover, I didn’t see this at all a couple of days ago, but now creating a simple Vue page with a button and text is being pursued by creating a motion.div.
Experiencing the same problem - since a couple of days Cursor keeps hallucinating ‘<motion.div’ in my Nuxt/Vue projects. Not sure if this is related, but it feels like at the same time the token costs have gone up a lot - like if this bug takes it a lot of tokens to fix. Adding a specific rule for this, using another model, etc hasn’t helped. I don’t use framer motion anywhere.
Hey, thanks for jumping into the thread. I see there are already a few reports and they started around the same time. This looks like a regression in model behavior, especially via auto, not an issue with the rules themselves. The fact that the rules don’t help is another signal.
To pass this to engineering with enough detail, can you help with a couple things:
The Request ID from a chat where the agent inserted the motion wrapper Chat context menu in the top right > Copy Request ID. Ideally 2 to 3 different ones so we can see which models auto picked when the bug happened.
Which model was selected if it wasn’t auto, please say it explicitly, like Claude 4.6 Sonnet, GPT-5.5, Composer, etc.
Whether the project uses framer-motion or motion-v or @vueuse/motion anywhere, even just in package.json.
As a temporary workaround, try explicitly pinning the model to Claude 4.6 Sonnet or GPT-5.5 instead of auto and see if it still happens. In our experience, different models handle motion wrappers differently, and auto can drift.
I’m tracking the issue and I’ll post an update here as soon as we have a fix. I can’t share an ETA yet.
Hey, thanks for the Request ID. The issue is confirmed on our side, and we’re already investigating.
As a temporary workaround, pin the model explicitly to GPT-5.5 or Claude 4.6 Sonnet instead of auto. Bek confirmed the issue went away after switching to GPT-5.5, and other users with Claude 4.6 Sonnet pinned can’t reproduce it either. Rules won’t help here.
Hey everyone, thread update: we’ve shipped a fix on our side. auto should no longer fall back to motion.* wrappers in Vue or React projects that don’t have them.
Can you check in your projects and let us know if everything looks OK? If you’re still seeing this behavior, please share a recent Request ID and the model name if you’re not using auto, and we’ll take a look.
Hey, thanks for the report and the Request ID, that’s exactly what we need. The fix we shipped was aimed at Vue and React detection, but your project is Astro, so it’s totally possible this path wasn’t covered. I’ll pass this to the team along with your Request ID and screenshots.
A couple quick questions so we can narrow it down faster:
Does your package.json include anything with the word motion (framer-motion, motion, @vueuse/motion, motion-v)? This includes devDeps, or something pulled in transitively via a UI kit.
If you switch from auto to Claude 4.6 Sonnet or GPT-5.5 explicitly, does the bug still happen in the same file? For other users, pinning a specific model made the issue go away.
For now, pinning the model is the most reliable workaround. Your rule is written correctly, it’s not the problem. In auto mode, the model still drifts into motion wrappers in some stack setups. I’ll reply in the thread once there’s an update on the fix status.
A lot of tokens are spent on such requests, where an error appears. Why do I have to pay for it out of my own pocket? 4.5 million tokens for cursor to write its own code to fix its own bug
Hey, thanks for following up. That confirms the regression that @i3D is also seeing on Astro. Looks like the fix didn’t cover all stack configs.
To pass a fresh signal to the team, could you send a new Request ID from a repro you did today Chat context menu in the top right > Copy Request ID. The old ID 0358dd1f-cc82-4b4b-a0ae-14c5a60d4062 was from before the fix, we need a post-fix one so it counts as a regression.
While we investigate, the temporary workaround is the same. Explicitly pin the model to Claude 4.6 Sonnet or GPT-5 instead of auto. On auto, the model still falls into motion wrappers in some stacks.
About tokens spent on the self-correction loop, that’s tied to your specific account usage and it’s handled by the team at [email protected]. Email them with the Request ID and a link to this thread and they can look into your case.
As soon as we have an update on the regression, we’ll post it here.
