Glob-scoped rules should trigger on AI file access, not just editor tabs — plus MCP/CLI tool triggers

Ideas Feature Requests
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Glob-scoped rules (globs: ["**/database/**"]) only activate when the user has matching files open in editor tabs. They do not activate when the AI reads or edits matching files via tool calls in agent mode. This means the AI misses domain-specific rules during autonomous work — the primary use case for agent mode.

Separately, there is no way to scope rules to MCP tool or CLI usage. Rules for Jira conventions, database query safety, or git workflows must be set to alwaysApply: true even though they’re only relevant when those tools are invoked. This wastes context window on every message.

Steps to Reproduce

  1. Create a rule with globs: ["**/database/**"] and alwaysApply: false
  2. Close all database/** files in the editor
  3. In agent mode, ask the AI to edit a database file (e.g., “add a column to the users table”)
  4. The AI edits database files but the rule never loads — it only checks editor tabs, not AI tool activity

For the MCP/CLI gap:

  1. Create a rule with Jira posting conventions and set alwaysApply: true (no other option)
  2. Have a conversation that never touches Jira
  3. The rule still loads every message, wasting tokens on irrelevant context

Expected Behavior

Rules should support triggers based on AI activity, not just editor state.

Proposed trigger types:

Trigger Fires when…
globs + scope: editor_open User has matching files open (current behavior)
globs + scope: ai_access AI reads/edits matching files via tool calls
globs + scope: both Either trigger
mcp_tools AI is about to call a matching MCP tool
cli_patterns AI is about to run a matching shell command

Example rule frontmatter:

---
description: Database conventions
triggerOn:
  globs:
    - "**/database/**"
  mcp_tools:
    - "sqlcl:*"
  scope: ai_access
---

---
description: Jira comment formatting
triggerOn:
  mcp_tools:
    - "user-mcp-atlassian:jira_*"
  cli_patterns:
    - "curl*/atlassian.net/*"
---

The rule injection pipeline already knows which files the AI is accessing via tool calls. Extending the glob matcher to also check AI file access (not just editor tabs) would fix the primary issue. For tool-scoped rules, adding optional mcp_tools and cli_patterns triggers would let rules load only when the AI is about to call specific tools — a natural extension as MCP adoption grows.

Operating System

MacOS

Version Information

Version: 3.0.4 (Universal)
VSCode Version: 1.105.1
Commit: 63715ffc1807793ce209e935e5c3ab9b79fddc80
Date: 2026-04-02T09:36:23.265Z
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.2.0

Additional Information

This disproportionately affects teams using agent mode for multi-file implementation and teams with MCP integrations (Jira, database, cloud APIs). As agent mode becomes the primary workflow, rules scoped only to editor state become increasingly unreliable.

Our team converted all 6 glob-scoped rules (~395 lines) to alwaysApply pointer rules with on-demand reference file reads as a workaround, resulting in ~414 lines of always-loaded context. The ai_access file trigger alone would let us cut that significantly while making rules more reliable during autonomous work.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @WD4Ever

Thanks for the detailed writeup!

To clarify how this works today: glob-scoped rules activate when the agent reads a matching file in agent mode. When the agent reads a file that matches a glob pattern, the matching rule content is automatically injected into the agent’s context for that step. So if you ask the agent to edit database/users.ts, the agent reads that file, the glob match fires, and the rule is applied. This is entirely based on the agent’s file access, not on which files you have open in the editor.

One thing that might be causing the issue here: the frontmatter syntax globs: ["**/database/**"] with JSON-style brackets isn’t supported by the parser. The brackets end up as part of the pattern itself, so it would never match. The correct syntax is a quoted string:

globs: **/database/**

For the second part of your request around scoping rules to MCP tools or CLI patterns, we’d recommend looking into Skills!

Skills are agent-requestable and only loaded when the agent determines they’re relevant based on the description you provide. So for something like Jira conventions, you could create a skill with a description mentioning Jira and MCP tool usage, and the agent will pull it in when it’s about to do Jira-related work, without burning context on every message like alwaysApply: true would.

7

Thanks Colin! We tested with the corrected syntax (plain string, no brackets):

globs: “**/database/**”

alwaysApply: false

The rule contained a unique marker phrase. We then had the agent read a file at project/database/data/override/test_table_diff.json via tool call in agent mode (Claude 4.6 Opus). The marker did not appear in the agent’s context — not on the turn the file was read, and not on the following turn. We also tested by @ referencing a matching file in chat — same result, no trigger.

Regarding Skills for MCP/CLI scoping — we already use Skills for workflows like Jira posting, peer review, etc. The glob request is specifically about domain conventions tied to file types (database sort order rules, XML element ordering, Perl override patterns). These are things the agent needs in context whenever it touches those file types, which is what globs are designed for.

One additional issue: glob rules also fire when a matching file is open in an editor tab even if the agent isn’t working on it. If I have a database file sitting open from earlier work but the agent is editing Helm charts, the database rule loads unnecessarily and consumes context. Ideally globs would be scoped to what the agent is actively accessing, not just what’s open in the editor.

8

Hey @WD4Ever

This one’s on me – there should be no quotes around "**/database/**". I’ve edited my last response.

globs: **/database/**

Having files open in the editor should not influence rule execution. The agent is aware of what files have been opened recently, but that doesn’t influence rule execution.

9

Thanks for the correction — removing the quotes fixed it. We tested all three syntax variants:

  • `globs: **/database/**` (no quotes) — **works**

- `globs: “**/database/**”` (quoted string) — does not work

- `globs:` with `- “**/database/**”` (YAML list) — does not work

We also confirmed that having a matching file open in an editor tab without the agent reading it does **not** trigger the rule, which matches what you described.

One issue we did find: glob rules created mid-conversation don’t take effect until you open a new chat. We created the test rule, had the agent read a matching file in the same chat, and the rule never injected. Opening a fresh chat and having the agent read the same file worked immediately. This could be confusing if someone creates a new glob rule and expects it to apply right away — it silently doesn’t until the next chat.

The syntax sensitivity is worth calling out in the docs. The YAML list format (`- “pattern”`) and quoted strings (`“pattern”`) are both natural things to write and both silently fail. A validation warning when a glob pattern contains quotes or brackets would save people a lot of debugging.

Thanks for the quick responses.

11

Yeah, we should better document this. I have a Docs PR under review!