Rules appear in <always_applied_workspace_rules> in the Agent system prompt
Cursor’s Agent session builder is treating them as always-on
Rules have no .mdc file on disk
They are server-side team rules, not local project rules
cursor/disabledTeamRules in state.vscdb explicitly lists all three
The user’s opt-out was recorded correctly by the UI
Rules still appear in the system prompt despite being in the disabled list
The Agent system prompt builder does not check disabledTeamRules before injecting team rules
Broken flow:
User toggles rule OFF in Cursor UI
↓
Cursor writes rule name to cursor/disabledTeamRules in state.vscdb ✅
↓
User opens Agent session
↓
Cursor fetches team rules from backend ✅
↓
Cursor builds Agent system prompt
↓
[BUG] disabledTeamRules list is NOT consulted ❌
↓
All team rules injected into system prompt regardless of user preference
Steps to Reproduce
Open Cursor Settings → Rules
Find a team rule and toggle it OFF
Verify via SQLite that the rule name was added to cursor/disabledTeamRules:
sqlite3 "~/Library/Application Support/Cursor/User/globalStorage/state.vscdb" \
"SELECT value FROM ItemTable WHERE key = 'cursor/disabledTeamRules';"
Open any Agent/Chat session
Ask the agent to describe its system prompt context (or observe context window usage)
Expected: Disabled rules should not appear in system prompt
Actual: Disabled rules appear as always_applied_workspace_rules
Expected Behavior
Disabled rules should not be loaded into the context
I can’t reproduce this. If I disable a rule on cursor.com, it no longer appears in the agent context. I’ve verified this with internal tooling that’s more reliable than asking the agent to self-report.
However, if a rule is active on cursor.com (and marked as optional) and you disable it locally in Cursor Settings → Rules, the rule is still injected into the agent prompt. That’s a confirmed bug on our end, and I’ve filed it internally.
If your case is specifically about disabling rules on cursor.com (not locally), could you try upgrading to the latest version and testing again? Also, make sure you’re testing in a new chat session. Existing conversations won’t pick up rule changes.
My mistake, I wasn’t precise.
The bug is indeed that it’s marked as optional and active in cursor.com, and disabled locally.
and still gets injected into the context.
As you confirm here, it’s apparently a bug. Thanks for confirming.
+1
My entreprise adds ~20 team-rules of which only 3 are mandatory but disabling (locally in cursor app) the optional ones, relaunching a new agent after closing/reopening the app, still adds all the team rules in the context (so even the ones I toogled off).
This consumes between 1/5 to 1/6 of the whole context window in my case which is wasted tokens/energy/money on every request. This is now more obvious thanks to the nice newly introduced feature that display the context usage per category.
Eager to see progress on this issue so we can stop wasting ressources.
This has been fixed in a recent update. You’re on 3.3.30, and the fix shipped in 3.4.12+. Please update to the latest stable release, then start a new Agent chat and check whether the disabled optional rules still show up in your context usage.
For reference, non-enforced Team Rules can be toggled off under Cursor Settings → Rules. Only rules your admin has marked as required stay on.
If you still see disabled rules in context after updating, please create a new thread with your Cursor version and a Request ID from a fresh repro and we’ll dig in.
