Hi,
I’m setting up a workspace containing multiple projects and need help understanding how Cursor handles rules. I want to apply different rules to individual projects while also having a set of global rules that apply across the entire workspace. I’d like to understand how Cursor processes these rules, what takes precedence when there are conflicts, and whether it’s even possible to set workspace-level rules.
Thanks!
Hey, currently, codebase indexing doesn’t work fully for workspaces where the files are not within the same base folder!
We’re hoping to have better support for this soon, but for now, you may notice some decreased performance in workspaces like you hope to use.
Regarding project rules, the AI agent evaluates each rule and decides which ones to use. The globs are the most precise way to define this, but your description for each should be a statement the AI can use to decide if the rule is needed, such as:
“Always use this rule”
“Use this rule when creating frontend React files”
" Use this rule when planning a new feature"
With a bit of experimentation, you’ll find what works best for you!
Thanks!
Same problem here. Cannot really work around this by having a single root folder.
Cursor only seems to take .cursor/rules from the first folder alphabetically, this is also where rules are created using the dialogue in Settings. If I create .cursor/rules in the other folders, they seem to be ignored completely.
+1! This would be really useful for working with microservices, and so all projects sharing a same style and cohesiveness
Same here, working with a multirepo workspace with a single root folder.
Cursor only takes the rules from the first repo.
{
“folders”: [
{
“path”: “arrow-parts-back”
},
{
“path”: “arrow-parts-front”
}
],
“settings”: {}
}
Bumped into the same problem 
What worked for me was to symlink the root project rules into the folder (subfolder of the project) that I load into cursor, as it seems to find the rules via the symlink.
Of course, a proper fix would be nice, but meanwhile this temporary solution will do.
Hi. See this perplexity answer, does this work for you? https://www.perplexity.ai/search/f46d94ed-371d-4d91-96f2-3d7a5ff40882
Ok, so my experience is workspaces are great when your debugging integrations, or in initial development.. but pretty quickly the rules implementations can become excessive ( and costly), and the agent can get confused which repo it should be working in ( i assume because of workspace indexing), particularly if your repos follow similar folder and naming structures.
Workspace rules would be nice, but I’m afraid it is likely to create just as much bloat, as repo level rules will still need to be the standard for reliability and cost mitigation.
