Fix
Cursor Ignoring My Rules? How to Fix .cursor/rules
Cursor ignores rules that are not scoped to the files you are editing. It also skips an agent-applied rule with no description for the agent to pick it up by, rules living in the legacy root .cursorrules file instead of .cursor/rules/*.mdc, and rules that are simply too long. Tighten the glob, fill in the description, migrate to .mdc and keep each rule short.
On this page
Why is Cursor ignoring my rules?
Usually the rule never loaded for the file you were in. A rule only applies when its globs match the open file, so a .tsx convention scoped to .css simply never fires. The other causes are mechanical: the rule lives in the legacy .cursorrules file, or it has grown long enough that the model dilutes it.
- The rule's globs don't match the files you're editing (or there are none).
- An agent-applied rule has no `description`. When
alwaysApplyis false, the description is what the agent reads to decide whether the rule applies. Leave it empty (with no globs) and the rule only fires when you @-mention it. - You're using the deprecated `.cursorrules` file instead of
.cursor/rules/*.mdc. - The rule is too long or contradictory, so it's diluted.
- Malformed `.mdcMarkdown-Cursor rule file. The file format for a Cursor rule; set always_apply to false and scope it so the rule only fires on the files that need it instead of burning context every request. Press Enter for the full definition.` frontmatter.
One cause is missing from that list because it produces no error anywhere: the extension. Project rules have to be .mdc. A .md file sitting in .cursor/rules/ is ignored by the rules system, since plain markdown carries no frontmatter to hold description, globs and alwaysApply. The file looks entirely correct in the editor, which is what makes this one expensive to find. If you would rather write plain markdown, AGENTS.md in the project root is the supported route, and nested AGENTS.md files apply to their own directory and below.
Before any of that, check where you tested it. Cursor's docs say rules do not affect Cursor TabCursor's original autocomplete: multi-line, edit-aware suggestions you accept with the Tab key. Press Enter for the full definition., and that User Rules apply only to Agent (Chat), not to Inline Edit with ⌘CtrlK. A convention you verified by pressing ⌘K and watching it get ignored may never have been in scope for that surface at all. Re-test in the agent panel before you start editing frontmatter.
This is covered hands-on in Troubleshooting and Operating Cursor Reliably — 7 short modules, free to read.
How do I make Cursor follow my rules?
Fix it where the rule lives, not in the prompt. Move each rule into its own .mdc file, scope it with globs so it loads on the right files and trim it down so the model can actually act on it. Keep one concern per file.
Scope a rule to the files it belongs in
0:47 · narratedRead this demo as text
- product-aware-development and AGENTS show no path next to them in Settings, Rules — they apply everywhere. search-scope carries a path, src/components/search, so it only attaches when a file under there is in play.
- Close Settings. Both open tabs, EmptyState and searchFilter, sit under that same path — the glob covers either file, not just the one you happen to be editing.
- Keep the glob as narrow as the behavior it changes. A rule with no path fires everywhere, even files it was never written for — a scoped rule stays quiet outside its own directory.
src/components/search, so it only attaches when a file under that path is in play, and the glob covers both open tabs, EmptyState and searchFilter.Practice next: Practice this yourself in the hands-on module.
Simulated Cursor 3.12 (macOS, light) — beta educational reconstruction, not the real product.
- 1Move rules to *`.cursor/rules/.mdcMarkdown-Cursor rule file. The file format for a Cursor rule; set always_apply to false and scope it so the rule only fires on the files that need it instead of burning context every request. Press Enter for the full definition.
** (one concern per file)./create-rule` in chat scaffolds one with valid frontmatter, or use Customize → Rules → Add Rule. - 2Set `globs` so the rule loads for the files it's about.
- 3Set `alwaysApply: false` on file-scoped rules so they fire only on matching files, not every request, and give agent-applied rules a one-line `description` the agent can match on.
- 4Shorten the rule to concrete do/don't lines with an example (the docs cap guidance at 500 lines; good rules are far shorter).
- 5Verify the frontmatter is valid; reload Cursor.
Scope comes before length here, and not as a matter of taste: the first three steps decide whether the rule loads at all, while step four decides whether the model can act on what it read. Shortening a rule that never loaded is work on the wrong half of the problem. Cursor's own troubleshooting note starts in the same place, with the rule type, then the description or the glob that type depends on.
When a rule kept getting missed, my instinct was to set alwaysApply: true and stop thinking about it. Scope it with globs instead. An always-on rule spends context on every request in the project, including the ones it has nothing to do with, so the flag trades a rule that fires too rarely for one that dilutes everything else.
Context is a scarce resource, so don't burn it running every rule globally. A Cursor field engineer's own team-kit rules run about eight lines. If yours pass ~100 lines, trim them or split into several file-scoped rules.
Contrary to popular belief, our rules are actually very short. It's only eight lines long. If you have rules that's over a 100 lines long, I would highly suggest you to trim it down.
If the rule looks correct but still gets dropped, check the conversation length. After a very long chat, the rule context can get overwritten just from filling up the window. The lean-rule fix and an empty-ish context work together: keep the rule specific, and let the agent do only the task at hand so its instructions aren't crowded out.
Which rule wins when two of them disagree?
Cursor merges every applicable rule and resolves conflicts by source, in this order: Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition., then Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition., then User Rules. Earlier sources take precedence, so a team rule outranks the .mdc in your repo, which outranks the personal preference you set in Customize.
Precedence goes by source, not by which file you edited most recently.
That ordering produces a failure that reads exactly like a rule being ignored. Your project rule loads, it is scoped correctly, and the model does something else anyway, because a team rule higher up the chain says otherwise. Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. with no glob set apply to every conversation, so on a managed install the thing overriding you may be a rule you have never read. Customize lists them under Team Rules.
The reverse case is a team rule nobody is following, and there the switch is on the member's side. Non-enforced Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. can be toggled off in Customize by each person; only a rule saved with Enforce turned on cannot. If an admin is asking why half a team ignored a standard, that checkbox is where I would look first.
Frequently asked questions
Is .cursorrules deprecated?
The single-file .cursorrules is legacy. Current docs no longer mention it. Use .cursor/rules/*.mdc files, which support per-path scoping via globs and are what current Cursor expects.
Does Cursor read AGENTS.md?
Yes. A plain-markdown AGENTS.md in the project root works as an alternative to .cursor/rules, and nested AGENTS.md files in subdirectories apply automatically to files in that directory and its children. Reach for .mdc rules when you need glob scoping or agent-requested application.
How do I scope a Cursor rule to certain files?
Add a globs array in the rule's .mdc frontmatter (e.g. ["**/*.tsx"]) and set alwaysApply: false. The rule then loads only when you work in matching files, instead of burning context on every request.
Cursor keeps writing tests that pass even when they should fail. Why?
AI-generated tests sometimes log a failure instead of calling the framework's fail(), or wrap assertions in a try-catch that swallows them. Make the rule lean and specific to that anti-pattern, keep the agent's context near-empty so the rule isn't overwritten, and add a validator step (a skill or sub-agent) that runs the test, reads the output and confirms a real failure surfaces.
Cursor keeps remaking my design-system components instead of reusing them. How do I stop it?
It is hallucinating its own icons, kerning and padding because it has no durable reference for yours. Put that context into a skill (skills are persistent Markdown that can also reference scripts and other files) so it's actually used. For example: 'every time you make changes, check the Figma design system in this skill and adhere to it.' A loose design.md works better when you fold it into a skill rather than leaving it on its own.
Sources & last verified
Cursor ships frequently. Last updated July 28, 2026.