`alwaysApply: true` rules are being completely ignored now

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Very recently, perhaps over the last several days, some version of Cursor has become bugged pertaining to rules. None of my rules with alwaysApply: true are being honored at all.

Specifically inquiring with Opus about this, I’ve been asking constantly why the rules are being ignored. It consistently states that (copy/pasting one instance): “The rule is in the agent-requestable workspace rules section, meaning it’s available to me but I have to actively pull it before it influences my behavior. I didn’t read it before composing the final message, so I defaulted to the long recap.”

It seemed to have been following another rule, so I asked why; but it turns out it wasn’t. It looked like it was following that rule only because surrounding code was already compliant so it was accidentally following it.

Further probing concludes that, in summary “The real fix is upstream of the agent: this is a Cursor problem, not just a discipline problem.” and “Both completion-summary.mdc and general.mdc have alwaysApply: true in their frontmatter. That flag is supposed to make Cursor inline the rule’s content into the system prompt of every conversation. Instead, both rules show up in my system prompt under <agent_requestable_workspace_rules>”.

I hope you look into this. It is VERY NOTICABLE when my rules are no longer being followed. This is a pretty new issue – it’s been great up until now.

Steps to Reproduce

Here is a general rule usable by any project that is being COMPLETELY ignored.


alwaysApply: true

Post-Completion Communication

After completing code changes or executing a plan, do not end with a recap of what was changed. The user can see diffs, tool call results, and file modifications directly. Restating them wastes output tokens and adds no value.

Specifically, avoid:

  • Bullet-point lists of files modified or created
  • “Here’s what I did” / “Here’s a summary of the changes” blocks
  • Paraphrasing the diff back to the user
  • Restating what was already visible in tool call output

A short, one-line confirmation like “Done.” or “All three files updated.” is sufficient.

When to Communicate More

Only provide more than a one-liner when one of these applies:

  1. Deviations – Something was done differently than the plan or the user’s instructions, and why.
  2. Decisions made – A judgment call was made during implementation that wasn’t pre-discussed.
  3. Incomplete work – Something couldn’t be finished, and what remains.
  4. Required follow-up actions – The user needs to do something manually (e.g., run a migration, update a config, restart a service).
  5. Non-obvious side effects – The changes have implications that aren’t apparent from the diff alone.
  6. Warnings or caveats – Something works but has a known limitation, edge case, or risk.
  7. User explicitly asks – The user requests a summary or explanation.

Even in exception cases, keep it brief and focused on what the user doesn’t already know.

Expected Behavior

In most of the work I do, I generally get a simple “Done.” at the end. Sometimes a few lines of bullets with caveats. Now I get the typical page worth of wasted tokens, which means wasted money.

Operating System

MacOS

Version Information

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
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.4.0

For AI issues: which model did you use?

Opus 4.7

Does this stop you from using Cursor

No - Cursor works, but with this issue

Same here: Very simple rule ‘Always applied’ is not added to the prompt. When reminded to follow [rule name] agent follows. In short: Always applied semantics violation. Really annoying when the most basic stuff is not working.

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
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: Linux x64 6.17.0-22-generic

Hi @RayGraham,

I can reproduce this. Rules with alwaysApply: true in .mdc files are being placed in the requestable section of the prompt instead of being directly injected, which is consistent with what you and Opus observed. This is a genuine bug, not model confabulation.

There’s a similar report on macOS 3.0.16 describing the same behavior. Our team is aware and investigating. To help scope the fix, a few things would be helpful:

  1. Request ID – Start a new Agent chat, send any message, then click the three dots (top-right of the chat) and select Copy Request ID. This lets us verify the exact prompt. How to find your Request ID

  2. Where are your rule files? In the project’s .cursor/rules/, in ~/.cursor/rules/ (user-level), or set up via Cursor Settings > Rules?

  3. How many rules do you have total, and how many have alwaysApply: true?

As a workaround, you can @-mention specific rule files in chat to force-include them in the conversation context. Not ideal with many rules, but it works until this is resolved.

@hermann-o – If you can share a request ID from your setup too, that would help us confirm whether the root cause is the same on Linux.

Hi @mohitjain ,

Great to hear that this is reproduced. Here is what you’ve asked for:

  1. RequestID: 292f78f0-54b5-4e52-bd85-c949da253e3f

  2. My rule files are in .cursor/rules, contained within each repository. I don’t have any user-level rules or any manually set up. They are all within source controlled mdc files.

  3. 9 rule files. 6 have alwaysApply: true

I have been using your mentioned workaround for now; but it’s not taking long for the context to get full and then gets summarized; those rules ultimately get flushed out when summarization happens, so it’s pretty flaky too.

Additional data point, Linux, slightly older build than the OP.

Same symptom as described: a rule file with alwaysApply: true in its front-matter is placed under agent_requestable_workspace_rules in the system prompt instead of being auto-injected. The agent confirms this when asked to quote its own prompt, and inlining the content via @-mention works as a workaround (same behaviour as in Mohit’s note).

Environment:

  • OS: Fedora 43, kernel 6.19.12-200.fc43.x86_64
  • Cursor Version: 3.1.15
  • VSCode Version: 1.105.1
  • Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
  • Build Date: 2026-04-15T01:46:06.515Z
  • Build Type: Stable
  • Electron 39.8.1 / Chromium 142.0.7444.265 / Node 22.22.1 / V8 14.2.231.22-electron.0

Rules setup (answering your 3 questions):

  1. Request ID: 699d3a2e-0574-4f1b-85a9-85119c9b4db0
  2. Rule file location: user-level, ~/.cursor/rules/global-conventions.mdc. No project-level .cursor/rules/ in this workspace, no Cursor Settings > Rules entries, no team plugin rules.
  3. Total rule files: 1. With alwaysApply: true: 1.

Front-matter of the file, for reference:

---
description: Global conventions and communication style
alwaysApply: true
---

Happy to provide logs or run a specific repro if useful.

Hi all!

This has now been fixed, and will be released in the upcoming 3.2 client release. Apologies for the inconvenience, and thank you for flagging!

2 Likes

Excellent; looking forward to the update. Thanks.

sample request:

6b7ca5d7-6c1a-47d2-8fcc-8e56b81de368