Plugins not loading from subfolders

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In our company we have several teams and repos in different stacks each with its own conventions and rules. Up until now we were using cursor rules for managing rules per project. However, we have recently moved to plugins and we are now finding an important blocker.
When the user opens the repo directly (ex: projects/projectA), the plugin discovery in projects/projectA/.cursor works and skills are listed in <available_skills>, in the IDE through the / and it is also shown in the settings->plugin section.

However, when Cursor is open from the parent directory (example: projects), none of the repo plugins are discovered automatically, and therefore not applied. For example, projects/projectA/.cursor or projects/projectB/.cursor plugins are not loaded, so none of their skills or hooks are applied.

This is very important for us since opening the parent folder gives cursor much more context than opening each one individually, and for many tasks we need the agent working across multiple repos, so opening the parent is super helpful. Same issue happens also if you open a new window and add folders to the workspace, none of those added folders include plugins.

Steps to Reproduce

Two different ways:

Parent folder

  1. Create a parent folder (ex: projects)
  2. Checkout 2 repos with plugins configured inside (ex: projects/projectA and projects/projectB )
  3. Open a new Cursor window on projects
  4. Show skills available. None of the skills defined in projectA or projectB enabled plugins listed

Workspace folders

  1. Open a new window with a project with plugins (ex: projectA)
  2. Do “Add Folder to workspace” and select projectB
  3. Show skills available. Skills defined in plugins from projectA are shown, but none of the projectB

The cursor settings–>plugins view also shows no plugins detected

Expected Behavior

Plugins from subfolders are also loaded in the cursor context, so the agent can make use of them when needed

Operating System

Windows 10/11
MacOS
Linux

Version Information

Version: 2.6.20
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hi @Angel_Garcia,

Thank you for the detailed report and clear reproduction steps.

This is a known limitation in how Cursor currently discovers plugins. Plugin loading is scoped to the primary workspace root only, which means:

  1. Opening a parent folder: Plugins in child directories (e.g., projects/projectA/.cursor) are not scanned

  2. Adding folders to a workspace: Only the first folder’s plugins are loaded; subsequently added folders’ plugins are not discovered

Our team is aware of this limitation and multi-repo support is being planned.

If it’s helpful, rules already have broader multi-root support. If some of what you need from plugins can be achieved with project rules (.cursor/rules/ files), those do get discovered from nested directories and multiple workspace roots.

7

Hi @mohitjain

Thanks for the answer. Indeed, we have been working for quite long with rules and they were loaded as you said. But actually, in rules we had the opposite issue. If you open multiple projects (for example in our ecosystem, we have dozens of microservices with the same cursor rules) and they contain the same rules, they are all loaded and repeated multiple times, leading to a major context bloat. That is part of the reason why we are moving to plugins instead.

For the record, what I am thinking now as workaround is to have some kind of hook in a team shared rule, that on session start inspects the subfolders and if it finds they have plugins (and the plugin is not loaded) then suggest the user to install it manually (on the parent folder or on his user space) for best results… not sure if this makes sense yet… happy to hear your opinion

8

Good context on the rules duplication. You’re right that this is a real issue – when you open a parent folder with multiple microservices that share the same rules, each copy loads separately into context because deduplication is path-based, not content-based. Our team is aware of this limitation.

On your proposed workaround – it’s actually closer to feasible than you might think, but with some adjustments:

  1. Use hooks.json, not a rule file. Rule files (.mdc) don’t support hooks, but you can define a sessionStart hook in a .cursor/hooks.json file at the parent folder level. This runs a shell script at the start of each conversation.

  2. The hook can inject context but can’t install plugins. A sessionStart hook can return additional_context (text injected into the conversation), so your script could scan subdirectories for .cursor directories and report what it finds. However, there’s no mechanism to programmatically install or enable plugins from a hook – the agent would know about the plugins’ existence but couldn’t use their skills or commands.

A more practical path for the shared pieces might be team marketplace plugins. Plugins distributed through the team marketplace load for all team members regardless of which folder is opened – they aren’t tied to a specific project’s .cursor directory. If your shared conventions (skills, hooks, commands) are consistent across projects, this avoids both the rules duplication problem and the subfolder discovery limitation.

Note: For project-specific plugins that differ across stacks, the subfolder limitation would still apply until multi-repo support is available.