# Nested git worktrees load duplicate .cursor/rules into context — please dedupe or let us scope rule discovery **URL:** \ **Category:** Bug Reports\ **Tags:** context, worktrees, rules\ **Created:** [June 20, 2026, 10:20pm UTC](https://forum.cursor.com/t/nested-git-worktrees-load-duplicate-cursor-rules-into-context-please-dedupe-or-let-us-scope-rule-discovery/163712 "2026-06-20T22:20:04Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![danpe](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/danpe/32/101098_2.png) [@danpe](https://forum.cursor.com/u/danpe)\ **Post date:** [June 20, 2026, 10:20pm UTC](https://forum.cursor.com/t/nested-git-worktrees-load-duplicate-cursor-rules-into-context-please-dedupe-or-let-us-scope-rule-discovery/163712/1 "2026-06-20T22:20:04Z")
### 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 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [June 22, 2026, 2:17pm UTC](https://forum.cursor.com/t/nested-git-worktrees-load-duplicate-cursor-rules-into-context-please-dedupe-or-let-us-scope-rule-discovery/163712/5 "2026-06-22T14:17:59Z")
Hey @danpe! Thanks for reporting. This is a known issue. > [@Bug Report: Always-applied rules duplicated across workspace roots in multi-root workspaces](https://forum.cursor.com/t/bug-report-always-applied-rules-duplicated-across-workspace-roots-in-multi-root-workspaces/151165/3): > > Hey, thanks for the detailed report. Cursor loads rules from each workspace root separately, with no deduplication. As a temporary workaround, you can keep .cursor/rules/ in just one worktree and remove it from the others in the workspace. It’s not ideal because you lose rule coverage when you open those worktrees on their own, but for now it reduces extra token usage. I’ve attached your report to the existing bug ticket.