Rules in ~/.cursor/plugins/local aren't injected correctly into the context window

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The markdown body of an alwaysApply rule file located in a local plugin e.g. ~/.cursor/plugins/local/my-plugin/rules/my-rule.mdc is not added to the context of new Cursor agent conversations.

Steps to Reproduce

  1. Create a rule file in a local plugin e.g. ~/.cursor/plugins/local/my-plugin/rules/my-rule.mdc
  2. Set alwaysApply: true
  3. Launch a new, separate agent and ask it about content that’s in the body of the rule. It doesn’t know anything about it. However, moving the rule file to ~/.cursor/rules/my-rule.mdc works fine.

When the rule file is in the local plugin location, Cursor only adds the description into the conversation’s context; when it’s in the global rules location, it only adds the body. I’m not sure if it’s supposed to add the description or if that’s just meant for humans…but it should definitely add the body.

Expected Behavior

Entire body of an alwaysApply rule is always added to the context of every new agent.

Operating System

MacOS

Version Information

Version: 3.2.11
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Thanks @Kevin_Scott,

We’re aware of the issue and shipped an initial fix in version 3.2. I’m checking with the devs, I think there’s a second layer we need to fix here! Plugin rules with alwaysApply: true AND a description are still mapped to agent-requestable instead being always applied.

11

Hi @Colin!

I developed a Cursor plugin with some important rules for our team workflow, but I’m facing the same problem reported here.

Having only alwaysApply: true without a description seem to be working for now, but that doesn’t feel like the best solution.

Do you have any news on the complete fix of this feature, please?

16

Hey @Cesar_Lima, We don’t have a specific ETA to share, but the team is actively looking at this. I’ll update this thread when the fix goes out. Until then, the workaround you shared seems to be the most reliable path.

17

This issue still exists in version 3.3.16