Trying to use indexing on a workspace with multiple folders, but it only indexes the codebase in the first folder and skips all the other folders in the workspace. Is this a known issue or a lacking feature? If not, what are the best steps to debug and resolve?
Deleting and resyncing index hasn’t helped.
Yea, codebase indexing only uses the first open folder in the workspace. As a workaround, you could try putting both folders into one parent folder and open that parent folder in Cursor.
Not sure if anyone thinks this would be worth a new feature, but I’d definitely like to have an option to index additional folders in the workspace.
+1 vote here
I have a monorepo and use workspaces to focus on the active projects. I could open the root monorepo folder as a workaround, but then I get a lot of noise that I’m not interested in.
+1 it is a must have, please consider adding the feature
+1 I wish we can just pick the folders to index as I prefer opening each folder in its own window even though the context should be shared across them.
Why would this only index one folder and not really explain it? This would be great to have a way to index multiple folders.
I have a go project which has multiple go modules in different folders in a single repo. We need a fix for this since the workaround to import the root folder does not work since the go language server expects the folder to be a go module and the root folder is not a go module. Is there a workaround for this?
I did also run into this issue here.
In my tests, the issue does not only occur when using an indexed repo, but even with indexing disabled. In a normal folder, Cursor creates a plan and queries folders and files live when not having an index, but in a workspace, Cursor does not receive any results from the query.
So it seems to have nothing to do with indexing per se, but actually file access on a lower level.
I would love to see this work.
Have there been any updates on this?
Same, this looks like an oversight that should be corrected. Makes multiple folders far less useful, also very confusing when the LLM can never follow code across the folders (very unexpected behavvior)
This also means that @Commit and @PR only relates to the first folder and thus can’t be used for changes in other folders/repos.
Agreed, would love to see this implemented. We have 3 massive repos with multiple projects each. I need to load one project from each repo into my workspace.
From a VS Code functionality perspective, it works great, but the composer AI features fail to see the other open projects.
Loading all 3 repos is not a great option since so many of the other projects are not directly related to my work and bloat context.
I’ve been patiently waiting for updates on this issue (almost a year!). Unfortunately, it seems the wind (if you’ll pardon the pun) is picking up. We’ve only heard from a community moderator, but no official follow-up from the development team itself. We are eager for a solution or at least an official stance on this. My concern is that, while the moderator is helpful, they might not have direct influence on project development priorities. Please let us know about these:
Thank you for your time and your hard work on Cursor. It’s a truly revolutional IDE that I admire and would like to continue using. We just need some reassurance that this overdue issue is on the team’s radar.