"Premium" mode feels sloppy and keeps ignoring really clean MDC rules!

Support Bug Reports
, ,
1

So basically we are facing the exact same problem now that we made the community aware in the topic:

and we got the response from the Cursor team that is intentional and well thought out change to eliminate custom modes and instead use MDC files as ruleset.
So what happens is basically the “Premium“ mode (which supposed to “intelligently“ choose models according to the context) is some of the cases totally, most of the cases (like 95%) partially ignoring even the simplest MDC always apply rulesets.
MDC rules was somewhat working with premium models before like 80% of the time kinda like they supposed to ( I am talking at this point about Opus and Sonnet models), but now the new “Premium“ mode just ignores even the simplest instructions.

As an example a given rule:
DURING THE ENTIRE CONVERSATION YOU CAN NOT USE RUN COMMANDS, YOU CAN ONLY READ, MODIFY, SEARCH, AND USE MCP BUT YOU ARE NOT ALLOWED TO RUN COMMANDS ANY KIND from the TERMINAL at ANY POINT!
Literally the first action by the agent is starting to run a terminal command. And this keeps happening again and again. And yes, the mdc file is in the correct location and run as Always Apply.

Like, yes, I understand the concept that the community would like to see more and more to be implemented, but this kind of slop is just totally breaks the development experience.

1 Like
3

It’s like with early image models, when you asked them NOT to draw any pink elephants. You got…

4

hi @HexadecimalHUN, thanks a lot for writing this up so clearly and for including the exact rule example.

First, on the behavior: all models should be taking project MDC rules into account, so it is absolutely fair that this feels wrong when you see your “Always Apply” rule being ignored. At the same time, the specific rule you shared

DURING THE ENTIRE CONVERSATION YOU CAN NOT USE RUN COMMANDS, YOU CAN ONLY READ, MODIFY, SEARCH, AND USE MCP BUT YOU ARE NOT ALLOWED TO RUN COMMANDS ANY KIND from the TERMINAL at ANY POINT!

is almost guaranteed to fail with current models, because it is framed as a global “do not” that directly fights how they are trained to be helpful in a coding environment (by running tools and commands).

A pattern that works much better is to give the model a positive role and a simple policy that explains why avoiding terminal execution actually helps it do a better job. For example, you could rephrase your rule along these lines:

For this project, your role is to work on code, not to execute terminal commands.
You are most helpful when you decide which commands are needed and propose them for me to run, so that I stay in control of my environment and you get clearer feedback about what happened.
Whenever a terminal command would be useful, you must:

  1. Decide what command should be run,
  2. Explain briefly why this command is needed and what it will do,
  3. Show the command in a code block for me to copy and run, and you must not execute the terminal command yourself

From the model’s perspective this is no longer “the user does not like commands”, it is “I am more effective if I plan and suggest instead of executing”, plus a clear 3‑step protocol it can repeat. That combination tends to be followed much more consistently than a single absolute “never run commands at any point”.

To help us check whether AI is still wiring MDC correctly on top of that, it would be very useful if you could add the standard bug details we ask for in the docs:

  • Cursor version (from Cursor > About Cursor in the menu bar)
  • Whether Privacy Mode was enabled when this happened
  • A Request ID from one of the runs where AI ignored your rule with privacy disabled
2 Likes
5

Thank you, this is a really helpful feedback, I need to rewrite my MDC rules accordingly!

6

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.