Cursor Rules Not Firing? alwaysApply, Globs & .mdc Explained

Your .cursor/rules/*.mdc file can be perfectly written and still never load. In Cursor, a rule is not “on” because it exists — it is on because the frontmatter chose one of four attachment modes: alwaysApply, globs (auto-attached), agent-requested (description), or manual (@-mention only). Get that wrong and it looks like Cursor is not following rules.

This guide is the deep dive for Cause 2 from that post: how alwaysApply, globs, and description interact in .mdc frontmatter — with examples you can paste, common silent failures, and when hand-tuned rules stop scaling for a team.

The four Cursor rule types (frontmatter → behavior)

Project rules live in .cursor/rules/ as .mdc files. Plain .md files in that folder are ignored by the rules system — Cursor needs frontmatter for description, globs, and alwaysApply. Under the hood, those three fields map to four behaviors:

The silent failure most people hit: they write a rule with no alwaysApply, no globs, and a weak or missing description. That collapses to Manual. The rule sits in the repo forever and never attaches until someone types @my-rule.

alwaysApply: true — use sparingly

When alwaysApply is true, Cursor includes the rule in every chat. Globs and description are ignored. That is powerful and expensive: every always-on rule competes for context with open files, chat history, and other rules.

---
alwaysApply: true
---

- Prefer named exports over default exports for application modules
- Never commit secrets or edit files under dist/ or build/
- When unsure about a pattern, read a nearby canonical file before inventing one

Practical budget: one short always-apply file for identity and hard constraints (often under ~50 lines). Put TypeScript style, React patterns, and API shapes on globs instead. If Agent feels “forgetful” or context-heavy, audit always-apply rules first — not the model.

Personal preferences that should follow you across repos belong in global user rules (~/.cursor/rules), not as always-apply project rules teammates inherit.

globs: auto-attach when the path matches

File-scoped rules are the default for most team conventions. Set alwaysApply: false and provide globs. Cursor auto-attaches the rule when a matching file is in context.

---
description: React component conventions for the web app
globs: src/components/**/*.tsx, app/**/*.tsx
alwaysApply: false
---

- Use named exports for components
- Co-locate styles next to the component
- Keep components under 200 lines; extract subcomponents in the same directory
- Prefer composition over deep prop drilling

Glob syntax that works

Official Cursor docs use a comma-separated string for multiple patterns (not a YAML list). If a rule refuses to auto-attach, convert array-style globs to the string form first.

Common glob mistakes

• *.tsx when you meant **/*.tsx — root-only match; nested components never trigger the rule
• Wrong package path in a monorepo — src/components/** will not fire for apps/web/components/**
• alwaysApply: true plus globs — globs are ignored; you paid always-on cost for a scoped rule
• Editing a file that is not in context — auto-attach keys off files the Agent actually sees; open or reference the matching path when testing

description without globs: Apply Intelligently

When you set a clear description, leave globs empty, and keep alwaysApply: false, Cursor presents the description to the Agent and lets it decide relevance. This is ideal for specialized domains that are not path-bound.

---
description: RPC service conventions — use when creating or editing backend services
alwaysApply: false
---

- One service per file under src/services/
- Validate inputs at the service boundary
- Return structured errors with code and message — never throw raw strings

A vague description (“coding standards”) gives the Agent nothing to match. Write the description like a routing label: what the rule covers and when to load it.

Recommended .cursor/rules layout

.cursor/rules/
  01-core.mdc              # alwaysApply: true  — short, repo-wide
  02-typescript.mdc        # globs: **/*.{ts,tsx}
  03-react-components.mdc  # globs: **/*.tsx
  04-api-routes.mdc        # globs: **/app/api/**/*.ts
  05-testing.mdc           # globs: **/*.{test,spec}.{ts,tsx}
  06-migrations.mdc        # manual or agent-requested — rare workflows

Split by concern. Keep each file focused and under a few hundred lines. Prefer pointing at a canonical example with @path/to/file over pasting a style guide into every rule.

Verification checklist (2 minutes)

1. Confirm the file is .mdc under .cursor/rules/ (not a plain .md, not legacy .cursorrules alone)
2. Open Customize → Rules and confirm the rule appears with the type you expect
3. For globs: open a matching file, start Agent chat, and ask which rules are in context
4. For always-apply: start a chat with no matching files and confirm the rule still loads
5. For agent-requested: give a task that matches the description and watch whether the rule attaches — if not, rewrite the description

When .mdc tuning is not enough

Frontmatter fixes load failures. It does not invent the conventions your team actually enforces in PR review. Hand-written alwaysApply / globs rules drift: one engineer updates React patterns, another still reviews against last quarter's API shape.

For long-lived team patterns, extract evidence from merged and closed PRs into shared Agent Skills and AGENTS.md. Codehabits does that automatically and keeps the output in the repo so every teammate's Agent starts from the same intelligence — while you keep short-lived or path-specific constraints in .cursor/rules/*.mdc.

npx @codehabits/cli enable
git add .codehabits/ .claude/skills/ .agents/skills/ AGENTS.md
git commit -m "chore: add team intelligence"
git push

Use both layers: .mdc for attachment control and temporary constraints; PR-derived skills for conventions that repeat in review. See also migrating Cursor rules to Agent Skills.

FAQ

What does alwaysApply do in Cursor rules?

alwaysApply: true includes the rule in every Agent chat. Globs and description are ignored. Reserve it for short, repo-wide constraints.

Why are my Cursor globs not working?

Check extension (.mdc), use comma-separated globs per the docs, prefer **/ for nested paths, and confirm a matching file is actually in the Agent context.

Should every rule use alwaysApply?

No. Most rules should be glob-scoped or agent-requested. Too many always-apply rules waste context and make it look like Cursor ignores the important ones.

Do .md files work in .cursor/rules?

No — project rules must be .mdc. For plain markdown without frontmatter, use AGENTS.md at the repo root (or nested) instead.

Where do global Cursor user rules live?

Under ~/.cursor/rules on your machine — see Cursor global user rules. Those are personal; project .mdc files are for the team.

Related guides

• Cursor not following rules — 3 causes
• Cursor global user rules (~/.cursor/rules)
• Migrate Cursor rules to Agent Skills
• Codehabits quickstart