Apply to Specific Files Rules are not reliably included for matching files in multi-root workspaces

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Apply to Specific Files Rules are not reliably included for matching files in a multi-root workspace.

I tested repository-local Project Rules using:

description: Adds a marker when editing Java files

globs: src/**/*.java
alwaysApply: false

The Rule is stored under repoB/.cursor/rules/ and the target file is under repoB/src/**/*.java.

The behavior is inconsistent. In some tests the Rule instruction was followed, while in others a matching repository-local Rule was not followed.

This matters in multi-root workspaces because alwaysApply: true is not a safe workaround for repository-specific Rules. An Always Rule from one workspace root can be included while Agent is working in another root.

So alwaysApply: false with globs is the intended automatic scoping mechanism, but it does not currently appear reliable enough to guarantee that a matching repository-specific Rule is included.

Steps to Reproduce

  1. Create a multi-root .code-workspace with two workspace roots:
    Workspace
    -repoA/ ← workspace root
    -repoB/ ← workspace root
    – .cursor/
    —rules/
    ----java-rule.mdc
    –src/
    —main/
    ----java/
    -----Test.java

  2. Add this Rule under repoB/.cursor/rules/java-rule.mdc:

description: Adds a marker when editing Java files

globs: src/**/*.java
alwaysApply: false

When editing a Java file, add this comment as the first line if it is not already present:

// MARKER_770

  1. Open both repoA and repoB as separate roots in the same multi-root workspace.

  2. Start a new Agent chat.

  3. Ask:
    Add a Hello World example to repoB/src/main/java/Test.java.

  4. Do not explicitly mention or open the Rule.

  5. Repeat the test in a new chat.

I also reproduced inconsistent behavior when both repositories had their own correctly scoped Rules using:

globs: src/**/*.java
alwaysApply: false

In that setup, one repository’s marker was missing while the other repository’s marker was added.

Expected Behavior

Because repoB/src/main/java/Test.java matches src/**/*.java relative to the repoB workspace root, the repository-local Rule should be included when Agent works with that file.

If the model follows the Rule instruction, MARKER_770 should be added.

For two repositories with separate correctly scoped Rules, each repository’s Rule should be triggered independently by matching files in that repository.

Operating System

MacOS

Version Information

Version: 3.15.6
VS Code Extension API: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 24.1.0
Workspace type: multi-root .code-workspace

For AI issues: which model did you use?

Auto

Additional Information

As an additional diagnostic, I asked Agent afterward which Rules had already been present in its context. In several tests, Agent reported that the repository-local Rule had not been part of its initial workspace-rule context and that it read the Rule during the task.

I understand that Agent self-report is not a reliable prompt trace, so I am not treating this as definitive evidence of when the Rule entered context. The main issue is the inconsistent generated behavior for matching repository-local Rules.

This appears related to existing reports about Apply to Specific Files / glob-scoped Rules not always being included reliably.

I can provide a minimal reproduction workspace if useful.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there, thanks for the detailed write-up. Your rule and glob look correct, and multi-root scoping is working as designed: a rule under repoB/.cursor/rules/ only matches files inside repoB.

“Apply to Specific Files” only attaches when a matching file is actually in context (you attach/@-mention it, or the agent opens it). If the agent edits or creates the file without opening it first, the rule never gets pulled in, which is why the same prompt can behave differently.

Reliable fix: @-mention or attach the target file (or one matching file in that folder) in the prompt so the rule resolves up front. Asking the agent to read the file before editing works too.

alwaysApply: true applying into repoA is expected today. Always-on rules at a workspace root cover the whole workspace, with no per-root scoping. Fair ask. We’ll be tracking this thread to gauge interest, which helps our product team prioritize. If others in multi-root setups feel the same, chime in here.

One caveat: attaching makes inclusion deterministic, not how closely the model follows the rule. If attach still misses on a pinned case, a minimal two-root repro would help and I’m happy to dig in.

8

Thanks for getting back to me so quickly, Mohit. This helps clarify the current behavior.

The workarounds are understandable, but they do not really fit our use case.

alwaysApply: true is not an option for repository-specific Rules in a multi-root workspace, since, as you explained, it applies across the whole workspace and can therefore influence work in other repositories.

Explicitly attaching or @-mentioning a file, or asking the Agent to read it first, makes the behavior more deterministic, but it also requires the user to remember an extra step.

For us, the main value of Apply to Specific Files is exactly that a Rule scoped by glob should be picked up automatically when the Agent works on a matching file. If the Agent can edit or create that file without the Rule being attached, then the behavior is difficult to rely on for repository-specific instructions.

So I think the remaining question is whether Cursor considers this the intended long-term behavior for Apply to Specific Files, or whether automatic matching on edit/create is something we should expect to improve.

9

Hi Mohit , just following up on this when you have a chance.

I’m mainly trying to understand whether the current Apply to Specific Files behavior is considered the intended long-term behavior, or whether Cursor expects to improve automatic Rule attachment when the Agent edits or creates a matching file without opening it first.

Thanks again for looking into this.