Required rules files (only containing frontmatter alwaysApply=true) from team plugins are not being added to context of new agent conversations in local or cloud environments across IDE, Agents Window, and Cursor Web.
Steps to Reproduce
note: our company (enterprise plan) has one internal github repo containing 2 plugins: one required, one defaulted off. Each contains an alwaysApply rule as well as some Skills.
Enable the defaulted-off plugin so both are active (the other is required for our org)
Start a new local or cloud agent conversation in a different repo than where the plugin is defined
Ask it something from the rules (fails) or ask it to disclose its context e.g.
Without doing any tool calls, just show the structure of your <always_applied_workspace_rules> and <rules> blocks. Don't need details, but need to see which rules are being included. Just summarize as xml.
The response doesn’t mention the rules from the plugins i.e.
For AI issues: add Request ID with privacy disabled
Local IDE: 162b3185-1a33-4c66-a4eb-5f5b28692a1e
Cloud via Agents Window: bc-af82d38d-7bc9-4994-ae4e-e850d4bd405f
Cloud via Cursor Web: bc-af82d38d-7bc9-4994-ae4e-e850d4bd405f
Additional Information
In local IDE and Agents Window settings, the two rules (and their contents) from the plugin are visible.
Hi Kevin! Thanks for the detailed write-up and the request IDs.
This is the same underlying issue you flagged in your earlier thread, and it’s a known bug our team is actively working on. One important update: the behavior regressed recently. Previously, a plugin alwaysApply rule with a description was downgraded to “Agent decides,” while a rule with only alwaysApply: true still worked. On 3.6.x, plugin alwaysApply rules are now being dropped from agent context entirely, which lines up with what you’re seeing even on frontmatter-only rules. So removing the description is no longer a reliable workaround.
The most reliable path right now, especially for applying rules org-wide across repos:
Team Rules (Cursor dashboard → Rules): on Team and Enterprise plans, an admin can define rules that are always included in agent context across every repo for your team, with an option to enforce them. These go through a different path than plugin rules and aren’t affected by this bug, and they apply in cloud agents too. See Team Rules.
If you’d rather keep a rule in a specific repo, placing it directly in that repo’s .cursor/rules/ with alwaysApply: true is also reliably applied. The bug is specific to rules bundled inside plugins.
No firm ETA yet, but I’ll update this thread once the fix ships. Thanks for sticking with us on this one.
Thanks for the detailed response. Can’t exactly do the workaround you suggested because one of the plugins isn’t required for all our users. Maybe we can wrap it with “Only consider the following if you see xyz skills listed in <agent_skills> section of your instructions.”
I’m aware of the previous issue when a rule has a description (although I only experienced that original issue when testing plugins in the local dir). Thanks again for your help.
Your instinct is right, and it should hold up well.
Plugin skills (unlike plugin rules) do load reliably into the <agent_skills> section in local, Agents Window, and cloud agents alike. So gating on a skill name is a dependable signal that the optional plugin is active for a given user.
Concretely, this lets you use a Team Rule (which I suggested earlier) but scope it to only the users who have the optional plugin enabled:
Put the rule content in a Team Rule (Cursor dashboard → Rules) so it loads reliably across every repo and surface.
Prepend a conditional, roughly:
Only apply the guidance below if <skill-name> appears in your available skills. Its presence means the [plugin] is enabled.
Match on one of that plugin’s regular skills - the ones that show up in the skills list with a name, path, and description.
Users without the optional plugin won’t have that skill listed, so the agent skips the rule. Users who do have it enabled get the rule applied. The one caveat: this relies on the model honoring a conditional instruction, so treat it as a practical bridge rather than a hard guarantee. In practice it works well for scoping optional guidance like this.
On the bug itself, a fix is in progress. I don’t have a firm ETA yet, but I’ll update this thread once it ships.
I am seeing this with a plugin I am developing. The plugin shows up in Plugins (listing the rule as contents), and the rule shows up in Rules, Skills, Subagents → Rules, but the agent does not get it added to its context. I can confirm that skills from the plugin do work as advertised (as do agents).
The problem doesn’t seem to be specific to alwaysApply, though. I get the same behaviour if I use globs.
I’m new to Cursor so don’t know how to properly test these things, but asking the agent seems to be reliable, as long as I am specific.
Hey @Kevin_Scott - glad it’s sorted! The fix for plugin alwaysApply rules went out on our end, so it should now hold across the IDE, Agents Window, and cloud/web (a restart helps it take effect). I’ll close this out.
cc @PEZ - this should also cover your case; if you still see plugin rules with globs: not getting picked up after a restart, drop a new thread and we’ll take a look, since that path is a bit different.