Been using cursor for over a year. Lots of benefits. Now I’m using it in a mono-repo and I’ve have a worktrees folder on the same level as the mono-repo - when I want to work on something I create a sparse worktree in the worktrees folder with just the particular app I want to work on in a folder named after the feature, and on a branch of the same name. I work there, get the job done, PR in, and then rarely go back to that instance of cursor in that worktree. Although occasionally I will do in order to refer back to the conversation there.
If I keep on doing this am I losing the benefit of cursor rag indexing of the code? Or is it just that a new index will be created each time that takes a while to be ready to go? If so is there some way to indicate to cursor how the worktree indices might be shared?
Yes, each worktree you open as a separate folder in Cursor is a separate workspace with its own index. Indexes aren’t shared between them automatically.
What this means in practice:
When you open a new sparse worktree, the index is created from scratch
Indexing is usually fast, depending on the size of the sparse checkout
Inactive indexes are deleted after 6 weeks
Since you’re using sparse worktrees (only the app you need), the index should build pretty quickly. You’re indexing just part of the monorepo, not the whole thing.
Right now there’s no way to tell Cursor to share indexes across your worktrees. But for sparse checkouts that’s usually not a big deal since the data size is small.
If you want to see indexing status: Cursor Settings > Indexing & Docs. It shows progress, and semantic search is available once the index is about 80% ready.
thanks for the explanation @deanrie very much appreciated - a related question is how we can have language specific rules work well in our monorepo - we have a mix of ruby and python (amongst others) and after having updated our ruby.mdc with several iterations of globs (still not sure if we need spaces between the globs or not) I think we have it so that if we specifically mention a ruby file in an instruction the ruby rules are followed, but when making a plan that happens to make edits to ruby files the rules are not necessarily followed - would be great if any time a model started to make changes it could have the file specific rules inserted into its context … happy to make this a separate topic if that’s easier?
Also is there a way to see which files have actually been indexed vs just % of the codebase?
По the second question first, it’s simple: Cursor Settings > Indexing & Docs > View included files. This opens a .txt file with a list of all indexed files.
About rules in a monorepo, it’s trickier. Here’s how rules work:
Injection (globs / alwaysApply): the rule is loaded into context
Activation (description): the AI decides whether to apply the rule
When you explicitly mention a Ruby file in your request, the globs match and the rule gets injected. But during planning, when the agent picks files to edit on its own, file-specific rules may not get picked up automatically. This is a known limitation.
Workarounds for a monorepo:
Use alwaysApply: true for critical rules (Ruby style, Python style)
In description, clearly say when to apply it, like “Apply when editing .rb files in apps/backend”
You can add a note in a global rule like “When editing Ruby files, follow @ruby-rules”
For globs, use the no-spaces format: `globs: [“/*.rb", "/*.rake”]
Thanks for the monorepo advice - we’ll try alwaysApply: true with some caveats
BTW, what I’d really really like is for cursor to index all my conversations and then be able to pull back in relevant stuff that we’d talked about, referring back explicitly to previous chats on the same project. Should I pop that in feature requests? I already have one in for interactive explicit chat summarisation More control over summarisation, ability to review and change
