Cursor Rules Not Working: Check Scope, Format, and Loading

Cursor rules stop working for a small set of reasons: the file is in the wrong place, the activation setting does not match the situation, the rule conflicts with another instruction, or the rule was loaded but the model ignored it. Each cause has a different fix. Working through them in order is faster than editing the rule repeatedly and hoping the next attempt lands. Tools like fenbs help by keeping a record of what each fix was, so the next session on this project does not start the same diagnosis from scratch.

Check the file format and location first

The most common reason rules do not load is a file in the wrong directory or with the wrong extension. Cursor reads rules from .cursor/rules/ at the project root. Files must have the .mdc extension. A file named rules.txt, placed in a subdirectory, or sitting at the project root instead of inside .cursor/rules/ will be silently ignored.

• Confirm the directory is .cursor/rules/ relative to the project root Cursor has open.
• Check the file extension is .mdc, not .md, .txt, or .cursorrules.
• If you are using the older .cursorrules file at the project root, it still works in current Cursor versions, but new rules should go in .cursor/rules/.
• On Windows, verify that the directory was not created with a trailing space or a different case. File system case sensitivity varies.

Verify activation scope

A rule file has an activation setting that controls when Cursor applies it. If the rule is set to auto-attach, Cursor applies it only when the active file matches the glob pattern. If the pattern is too narrow, the rule never fires. If the rule is set to always-apply but a different session type is active, it still may not appear in the context.

• Open the rule file and check the frontmatter. The alwaysApply: true setting makes the rule active for all files and sessions in the project.
• If globs is set, check that the pattern matches the file you have open. For example, **/*.ts matches TypeScript files but not *.tsx or *.js files unless both are included.
• Use a specific test: open a file that should trigger the rule, type a message in Cursor, and check the rule citations at the bottom of the response. If the rule does not appear in the citations, it did not load.
• For agent mode sessions, rules with alwaysApply: false that depend on file context may not load if the agent is working across multiple files. Use alwaysApply: true for rules that must hold throughout a session.

Look for conflicting instructions

A rule may load correctly and still be overridden by another instruction in the context. System prompts, other rule files, and the user's own message can all conflict. When two rules contradict each other, the model uses judgment about which to follow, and that judgment is inconsistent. The fix is to remove the conflict.

• Check whether another rule file has instructions that contradict the one you are testing. Two rules saying opposite things about indentation or naming will result in neither being reliably followed.
• If you added custom instructions in Cursor Settings, check whether they conflict with the project rule file.
• A message in the conversation that says "ignore the rules for this task" or "use a different approach" overrides the rule file for that exchange. This is expected behavior, not a bug.
• Rules that say "never do X" are followed more reliably than rules that say "prefer not to do X". State constraints clearly and specifically.

Rule loads but the model still ignores it

If the rule appears in the citations but the response does not follow it, the rule may be too vague for the model to apply consistently. "Write clean code" does nothing. "Use 2-space indentation and single quotes in all TypeScript files" is testable. Rewrite vague rules as concrete, checkable instructions.

• Replace adjectives with measurements: "short functions" becomes "functions of 30 lines or fewer".
• Replace intent with action: "handle errors properly" becomes "wrap all async calls in try/catch and log the error with the function name and input".
• Break compound rules into separate instructions. A rule with 15 points is harder to follow completely than three rule files each with five.
• Remove rules you no longer enforce. Outdated rules add noise and make the model uncertain about which instructions still apply.

Keep a record of what fixed it

Once you find the problem, record what it was and what the fix was. The next person on the project, or you in three months, will save an hour by reading one sentence. If the rule was in the wrong directory, the note says "rules must be in .cursor/rules/ not at the project root." If a glob pattern was wrong, record the correct pattern and what it targets. A short note is more useful than a comment in the rule file because it captures the diagnosis, not just the result.

How to do this with fenbs

1. Create a free account and add the project where the rule problem occurred.
2. Add a lesson in fenbs: describe the symptom ("rules were ignored on component files"), the cause ("glob pattern was *.ts, not *.tsx"), and the fix. Link it to the current project.
3. Record any standing rule about how Cursor rules are structured in this project as a Decision in fenbs, for example "all rules use alwaysApply: true for this project". Future sessions read it first.
4. Connect Cursor to fenbs over MCP from Integrations. Ask it to read the project context, including lessons, before starting a session where rules are involved.
5. If the same rule problem appears on a different project, check fenbs lessons first before diagnosing from scratch.

For the agent-level version of this problem, see the Cursor agent not working guide. The Cursor rules hierarchy guide explains how rule files interact when several are active at once.