Cursor ignoring your rules? Here's why (it's probably the .cursorrules migration)

You wrote a rule telling the agent to always use a specific import style, or never touch a certain folder, or always write tests a certain way. You saved it. The agent immediately ignored it — not by disagreeing, just by acting like the rule doesn’t exist.

If you’re searching “cursor rules not working,” “cursorrules ignored,” or “cursor not following my instructions” — this is almost never the model being stubborn. It’s Cursor’s rules system silently failing to load or scope your rule, and there are four specific, checkable reasons why.

Why this happens: two rules systems, one migration

Cursor used to read a single root-level .cursorrules file. That format still works for backward compatibility, but it’s deprecated — the current system is Project Rules: a .cursor/rules/ directory containing individual .mdc files, each with its own frontmatter controlling when it applies.

That “when it applies” part is where almost every silent failure comes from. Each .mdc rule file has metadata fields — description, globs, and alwaysApply — and the rule only fires under specific conditions:

• alwaysApply: true — the rule is injected into every request, full stop.
• alwaysApply: false with globs set — the rule only applies when a file matching that glob is part of the current context (open, edited, or referenced).
• alwaysApply: false with no globs and just a description — the rule is only pulled in when the agent itself decides the description matches the task (model-invoked, not guaranteed).

If you wrote a rule expecting it to apply everywhere but left alwaysApply unset or false with a narrow glob, it’s working exactly as configured — it’s just not configured the way you assumed. Separately, User Rules (set in Cursor Settings, account-level) are a different mechanism entirely from Project Rules (repo-level, in .cursor/rules/) — a rule you set in one place doesn’t show up in the other, and it’s easy to edit the wrong one and wonder why nothing changed.

The four things to check, in order

1. Are you editing a rule that’s actually loaded? If you still have a root .cursorrules file and a .cursor/rules/ directory, both can be read, but precedence between overlapping instructions isn’t something to rely on — treat this as a migration you haven’t finished, not a supported dual-config. Move everything into .cursor/rules/*.mdc and delete the old file once you’ve ported its content.
2. Check the frontmatter is valid YAML. An .mdc file’s frontmatter block (description, globs, alwaysApply) has to parse cleanly. A missing quote, a bad indent, or a stray character in the frontmatter is enough for Cursor to fail to load that rule — with no error surfaced in the chat. Open the file and check it against a rule you know works.
3. Check alwaysApply matches your intent. If you want a rule enforced on every request regardless of what files are open, it needs alwaysApply: true. If you only want it active for a specific file type or folder, alwaysApply: false with a globs pattern scoped to that path is correct — but then it genuinely won’t fire outside that scope, which is easy to forget three weeks later when you’re editing a different file and wonder why the rule didn’t apply.
4. Check you’re editing the rule in the right project. Project Rules live per-repo in .cursor/rules/. If you work across multiple repos or worktrees, it’s easy to add a rule in one checkout and then open the agent in a different one — the rule simply isn’t present there because it was never copied.

Reproducing and confirming

1. Open a file in the scope your rule’s globs should cover (or any file, if alwaysApply: true).
2. Ask the agent to do something that would visibly obey or violate the rule (e.g., if the rule bans a specific import, ask for a change that would naturally use it).
3. If the rule doesn’t apply, check Cursor’s rules list in Settings → Rules, which shows every rule Cursor has actually loaded, with its scope. If your rule isn’t in that list at all, it’s a loading failure (check frontmatter). If it’s in the list but didn’t apply, it’s a scoping issue (check globs / alwaysApply).

The actual fix

Consolidate on .cursor/rules/*.mdc only, give every rule you want enforced everywhere an explicit alwaysApply: true, and validate the frontmatter of any rule that isn’t showing up in Settings → Rules. Don’t rely on the model to infer intent from a description-only rule if the behavior is something you need guaranteed — description-only rules are a suggestion to the agent, not an instruction it’s required to follow.

Once a rule shows up correctly in Settings → Rules with the scope you expect, it’s not a “maybe” anymore — that list is ground truth for what Cursor actually loaded, which is the thing to check first the next time a rule seems to be ignored.