Why Cursor Rules Get Ignored in Agent Mode
A rule sitting in .cursor/rules that Cursor's agent seems to ignore usually isn't being ignored at all. It never loaded. Cursor decides whether to pull a rule into a session based on the rule's type, and three of the four types are conditional by design: a rule that auto-attaches only fires when a file matching its globs pattern is already in the chat's context, a rule that relies on the agent's own judgment only fires if the model reads its description and decides the current task is relevant, and a rule marked manual only loads when someone types @ and its name. Only a rule with alwaysApply: true in its frontmatter loads on every single request. If a rule doesn't say that, something else has to trigger it, and a normal agent-mode session routinely finishes a task without ever hitting the trigger.
The second most common cause is the file itself, not its type. Cursor's current rules documentation states that a plain .md file dropped into .cursor/rules is skipped by the rules system outright, because it carries no frontmatter to declare description, globs, or alwaysApply in the first place; it needs the .mdc extension and that YAML block just to be read. The older format, a single .cursorrules file at the project root, fares worse. It doesn't appear anywhere in that documentation anymore. Cursor has moved fully to the .cursor/rules folder and AGENTS.md, so a leftover .cursorrules file from an older project setup may not be doing anything at all.
How Cursor decides which rules make it into a session
Three fields in a rule's frontmatter, alwaysApply, description, and globs, determine which of four behaviors you get, and only one of them is unconditional:
alwaysApply: trueloads the rule on every request, and Cursor's docs are explicit that when this is set,globsanddescriptionare ignored entirely, so filling in all three doesn't stack conditions, it just wastes two fields.alwaysApply: falsewith adescriptionand noglobshands the decision to the agent: it reads the description text and decides per task whether the rule is relevant. A vague description ("coding standards") gives the agent nothing to match against and it skips the rule more often than a specific one does.alwaysApply: falsewithglobsset attaches the rule automatically, but only once a file matching that pattern is already part of the conversation. Ask agent mode to make a cross-cutting change that never opens a matching file directly, and the rule stays dark for the whole session.- Neither
descriptionnorglobsset means the rule only loads when someone manually references it with@rule-name. That's fine for a rule you invoke on purpose and a silent no-op for one you expected to run in the background.
If a rule you wrote isn't showing up in agent mode, this is the first thing to check, not the wording inside the rule.
Background and cloud agents have their own version of this bug
Rule-loading gets worse, not better, once work moves off your machine. A forum thread reporting background agents failing to load AGENTS.md describes GitHub-, Slack-, and web-triggered background agents that, when asked directly, confirm the file's contents were never in their context, even with the exact same file working in a local session. Other users in the thread report the same gap for .cursor/rules/ files specifically, not just AGENTS.md. A Cursor team member acknowledged the reports twice, collecting background agent IDs to investigate, with no fix or root cause posted in the thread as of this writing. If a rule works locally but a cloud or background agent acts like it was never there, that's this open issue, not a mistake in your setup.
When "list the priority customers" stopped working
This one covers two different failures back to back: a rule that never loaded at all, then the same rule loading exactly as written and going stale anyway. At Voltframe, which builds fleet-charging software for delivery companies, most of the bug backlog lands on one engineer: Greta Solberg. In July she wrote a rule to stop Cursor's agent from treating every open bug the same way:
.cursor/rules/priority.md: Treat bugs affecting Rundale Fleet and Baycrest Fleet as highest priority. Both are enterprise accounts closing renewal this quarter.
It never fired. The file had no frontmatter, so it wasn't a rule at all as far as Cursor's rules system was concerned, just an inert markdown file sitting in the right folder. She fixed the extension and format, added alwaysApply: true, and the agent started reading it correctly. For about six weeks, that was enough.
Greta, in Cursor's agent chat: Should I fix the CSV export bug or the webhook signature bug first?
Agent: Based on
priority.mdc, Rundale Fleet and Baycrest Fleet are flagged as top priority. Neither bug report mentions those accounts by name, so I don't have enough information to rank them from the rule alone.
The rule was loading exactly as written. The problem was what "as written" meant three months later. Rundale's renewal had closed, a different account, Corrisand Transit, was now the one escalating hardest, and nobody had gone back to edit the file, because editing a rules file isn't part of anyone's weekly routine. A static list is only current the day someone remembers to update it, and account priority doesn't hold still that long.
Why a well-maintained rules file still falls behind
A rules file, loaded correctly, still only contains what a person wrote into it, whenever they last wrote it. It can't reflect a customer who escalated an hour ago, a deal that closed last week, or a bug report that arrived after the rule was last edited, because none of that data lives in the repo the rule sits in. Past a handful of stable facts nobody minds re-typing occasionally, that gap is structural, not a configuration mistake to fix.
This is the point where the context has to arrive per task instead of living in a file. Modem reads Slack, support tickets, and sales calls continuously and keeps a live account and topic graph instead of a document someone maintains by hand. Through the Cursor integration, the Modem agent can hand a task straight to Cursor's Cloud Agents with the relevant bug reports and customer quotes already written into the task description, current as of the moment the task is created rather than the last time someone edited a rules file. Cursor also reaches the same graph directly over Modem's MCP server, so an agent working locally can ask which customers are hitting a given bug and how it stacks up against everything else in the queue, and get an answer clustered and prioritized from this week's tickets, not July's markdown file. We build Modem, so weigh that against the honest tradeoff described in the six best tools to give Cursor customer context. A rules file is free and needs a maintainer; a connected context layer costs something and doesn't.
Audit your rules folder before you write another rule
Open .cursor/rules and check every file for two things: does it end in .mdc, and does its frontmatter say what you think it says. Delete or convert a leftover .cursorrules file at the project root; current Cursor doesn't document it and may not be reading it. Then look at each rule and ask whether the fact inside it is one that holds still, like a coding convention, or one that changes on its own schedule, like an account's priority or a deal's status. The second kind is the one worth moving off a file entirely, and it's usually the one someone already noticed had gone stale before they thought to ask why.
