DEV Community

Ned C
Ned C

Posted on

Cursor Agent Mode Ignores .cursorrules — Use .mdc Instead

#cursor #ai #coding #productivity

:14: SyntaxWarning: invalid escape sequence '\ '
:15: SyntaxWarning: invalid escape sequence '\ '

:20: SyntaxWarning: invalid escape sequence '\ '

title: "Cursor Agent Mode Ignores .cursorrules — Use .mdc Instead"
published: true
tags: cursor, ai, coding, productivity

series: cursorrules-that-work

Edit (Feb 16): After further testing prompted by Colin from Cursor support, the original claim that .cursorrules is "ignored" in agent mode was too strong. Both .cursorrules and .mdc files load and apply. However, when both exist, .mdc takes precedence on any conflicting rules. In our original tests, the experiment workspace had .mdc files present, which explains the 0/9 result. In a clean project with no .mdc files, .cursorrules works normally. The recommendation to use .mdc is still valid (alwaysApply, glob scoping, and precedence are real advantages), but .cursorrules isn't silently broken. Original article follows with corrections noted inline.

I spent an afternoon running tests on Cursor's rules system because I wanted to know if file length affected how well rules get followed. I set up three .cursorrules files — short (19 lines), medium (90 lines), and long (576 lines) — all containing the same target rule. I ran each one three times through cursor agent and checked whether the rule was followed.

The result: 0 out of 9.

Not "worse with longer files." Zero. Across all lengths. The rule was ignored every single time.

It wasn't a framing problem

My first thought was that the rule was too soft. So I rewrote it with exclusive framing — "ONLY create files that begin with // GENERATED on line 1. NEVER create a file without it." Ran it again.

Still nothing. 0 out of 1.

.cursorrules wasn't being loaded

I switched from .cursorrules to a .cursor/rules/test.mdc file with alwaysApply: true in the frontmatter. Same rule, same prompt, same setup.

It worked. First try.

I ran it 9 more times across all three file lengths. 9 out of 9. The rule was followed every time — short, medium, and long files all hit 100%.

The original experiment didn't test file length at all. It tested whether .cursorrules gets followed in agent mode. In our workspace (which had .mdc files from other experiments), it didn't — because .mdc takes precedence on conflicts.

.cursorrules vs .mdc isn't even a contest

I also tested having both files present — .cursorrules saying one thing and .mdc saying the opposite. The .mdc rule won every time, 6 out of 6 runs. .mdc has higher priority — when both exist with conflicting rules, .mdc wins.

alwaysApply: true isn't optional

I tested this directly. Two identical .mdc files, one with alwaysApply: true and one with alwaysApply: false.

  • alwaysApply: true: 3/3 rule followed
  • alwaysApply: false: 0/3 rule followed

If you skip that flag, the file exists but the agent doesn't use it.

What happens when .mdc files conflict

I set up two .mdc files with contradictory rules — one said "ONLY use single quotes" and the other said "ONLY use double quotes." Both had alwaysApply: true.

The agent didn't pick one and hope for the best. It stopped, told me the rules conflicted, and asked which one to follow. This happened 3 out of 3 times.

That's actually good behavior. Silent inconsistency would be worse.

"Clean up" is the dangerous prompt

I tested whether Cursor strips comments during refactoring. I had a file with 17 comments — some were compliance notes (SOC2, GDPR), some were JIRA references, some were structural ("Step 1", "Step 2").

With a normal "refactor to early returns" prompt: all 17 comments survived, with or without a preserve rule.

With a "clean up, simplify, remove complexity" prompt: 0 out of 17 survived. Every comment was gone. The model treated comments as complexity to remove.

Adding a "preserve all comments" rule brought it up to 10 out of 17. The model kept the compliance and business logic comments but still removed the structural ones. Better, but not perfect.

Exclusive framing can break your code

I already knew exclusive framing (ONLY/NEVER) gets followed more reliably. But I tested what happens when the rule conflicts with what the code actually needs.

The rule was "ONLY use const for variable declarations." The task involved a counter that needed incrementing.

  • Exclusive framing: 2 out of 3 runs used const for the counter. The code was broken — you can't increment a const. One run found a workaround using an object.
  • Softer framing ("prefer const"): 1 out of 3 broke, but another run correctly used let for the counter, ignoring the rule when it needed to.

Use ONLY/NEVER for rules that genuinely have no exceptions — file creation boundaries, formatting standards. Use softer framing for things where the model should use judgment.

New files drift without rules

When I asked Cursor to add validation to an existing file that already had a custom error class, it used the custom class naturally. With or without a rule.

When I asked it to create a new file in the same project, it defaulted to generic new Error(). The custom error class was right there in the codebase, but the model didn't carry the pattern into new files.

Adding an explicit "use CustomError for all error handling" rule in .mdc fixed it. But without the rule, every new file is a small drift away from your conventions.

The setup that actually works

Based on all of this:

  1. Use .cursor/rules/*.mdc files, not .cursorrules
  2. Set alwaysApply: true in the frontmatter of every rule file
  3. Use exclusive framing (ONLY/NEVER) for hard rules with no exceptions
  4. Use softer framing (prefer/please) for rules where the model should use judgment
  5. Add a "preserve comments" rule if you use "clean up" style prompts
  6. Set explicit rules for conventions you want in new files, not just existing ones
  7. Check for contradictions between .mdc files before starting a session

The common advice — "just put your rules in .cursorrules and keep the file short" — isn't supported by the data. File length didn't matter. The file format did.

I ran these tests with Cursor CLI (cursor agent --print) on CLI version 2026.02.13-41ac335 (originally reported as IDE version 2.4.35). Results may differ in the GUI editor, and Cursor's behavior could change with updates.

If you want a quick reference for all of this, I put together a free safety checklist based on these findings. One page, no email required.

Top comments (0)