Nested git worktrees load duplicate .cursor/rules into context — please dedupe or let us scope rule discovery

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When git worktrees live inside the open workspace, Cursor discovers and attaches the .cursor/rules/*.mdc from every worktree. Because each worktree is a full checkout of a repo that commits its rules, the same rule file gets loaded once per worktree. With many worktrees this dominates the context window, and there is currently no setting or ignore file that stops it.

Steps to Reproduce

Open a repo in Cursor that commits rules (.cursor/rules/*.mdc).
Create a few git worktrees inside the workspace:
git worktree add worktrees/branch-a
git worktree add worktrees/branch-b
git worktree add worktrees/branch-c
(Each is a full checkout, so each gets its own copy of .cursor/rules/.)
Start a new chat in that workspace.
Open the Context Usage report (or check the rules attached to the turn).
Expected: each rule file is counted once. Actual: every rule file is loaded once per worktree — e.g. 3 worktrees → ~3× the rule tokens; the Rules bucket balloons to a large share of the context window.

Expected Behavior

Either (a) Cursor deduplicates identical rule files, or (b) Cursor doesn’t recursively pull .cursor/rules from nested worktrees/checkouts, or (c) there’s a documented way to scope rule discovery to the workspace root.

Workarounds that do NOT work

worktrees/ in .cursorignore → no effect.
.cursorignore only governs indexing / semantic search / @-mentions, not rule discovery.
worktrees/ in .gitignore → no effect. Rules are read from disk regardless of git status.
No Cursor setting exists to confine rule scanning to the root .cursor/rules.

Operating System

MacOS

Version Information

Version: 3.8.11
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: glass
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.256
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @danpe!

Thanks for reporting. This is a known issue.

I’ve attached your report to the existing bug ticket.