I’m reaching out with a question about organizing a workflow using the plugin system for managing agent configurations (rules, skills, etc.). I’d appreciate any recommendations or clarifications.
Problem
I often work with projects that share a common codebase. Such projects require a unified set of rules and skills for agents, while other projects use different configurations.
Currently, I’m forced to duplicate configuration files (rules and skills) across projects manually. This creates the following difficulties:
When I need to refine a rule in one project, I have to simultaneously apply the same changes to all other projects where that rule is used.
This approach requires constant context switching and carries the risk of forgetting to update a copy, leading to inconsistencies in agent behavior across projects.
Plugins
I tried using Cursor’s plugin. I created a plugin with shared rules and installed it locally from a folder into the target projects through the interface. At installation, the rules applied correctly.
However, during use, I found that changes made to the plugin’s source code (e.g., to rule or skill files) do not propagate to projects where the plugin is already installed. To apply updates, I have to remove the plugin from each project and reinstall it.
I suspect this behavior is because Cursor caches the plugin’s content globally.
Desired Workflow
To improve development efficiency and reduce unnecessary steps, I would like to be able to organize local plugin development as follows:
Create a local directory on my machine that acts as a marketplace (e.g., ~/cursor-plugins/), where I develop and refine plugins.
Connect a plugin to a project through Cursor’s standard interface, pointing to this local marketplace (or simply installing the plugin from a local source).
When I make changes to plugin files (rules, skills), these changes are applied automatically and instantly to all projects using that plugin — just as if I had edited the rules directly in each project.
No need to run git push, reinstall the plugin, or perform any extra steps to apply updates.
This would let me iteratively improve agent configurations on the fly while working on projects, without the distraction of manual synchronization.
Questions
Is the described behavior (global plugin caching) by design, or is it a technical limitation that might be reconsidered in the future?
Are there any working workarounds in the current Cursor version (e.g., using global rules, symlinks) to achieve a similar effect?
Is support for local plugin development with automatic sync across all projects planned for future releases?
I would be grateful for constructive answers, advice, and perhaps confirmation from the developers that this scenario is on the roadmap.
How did you install it exactly: through /add-plugin, or from ~/.cursor/plugins/local/?
There is a known issue with GitHub plugins added through /add-plugin: they can stay pinned to the first commit, so Update/Reinstall does not fetch later changes. Local development plugins are a different case.
Installing via ~/.cursor/plugins/local/ is inconvenient because it applies globally to all projects, and there’s no way to enable/disable them on a per-project basis.
I tried using GitHub. When I tried to update the marketplace with agent plugin marketplace update {marketname}, nothing would actually update.
I also tried the local installation method from the ~/cursor-marketplace/ directory, but that also doesn’t update when I make changes, just like with GitHub.
I tried creating symlinks in projects pointing to .cursor/rules → ~/cursor-marketplace/plugin-name/rules. That works. But the idea is that these rules shouldn’t be stored inside the project itself, which means they need to be in .gitignore. But if they’re in .gitignore, Cursor doesn’t see them and ignores them.
So overall, it seems like this is a bug with the marketplace plugin update mechanism. If it updated properly, the situation would be much better. Right now, it feels like I’m just stuck waiting for a fix.
Hey! For this exact workflow, don’t install the plugin from a folder into each project - develop it directly in ~/.cursor/plugins/local/<your-plugin>/. Everything in that folder loads live across all your projects, so edits to rules/skills apply everywhere after a window reload (Developer: Reload Window), with no git push and no reinstall.
By design - installing a plugin (folder or marketplace) pins and caches a copy, so edits to the original source don’t propagate. It’s not something on your end; the local-dev folder above is the path meant for live iteration.
Workarounds: the local-dev folder is the reliable one. Symlinks only work if the real folder lives inside~/.cursor/plugins/local/ - a symlink pointing to a repo elsewhere won’t load right now, so put the actual folder (or a copy) there. User Rules also work if you only need shared rules (not skills or other components).
Cross-project live sync already works via that local folder. Smoother version/update management for installed plugins is something we’re tracking - no timeline, but I’ll post here if there’s an update.
Installing in ~/.cursor/plugins/local/ doesn’t allow selecting a specific project for the plugin. In the popup menu, the project selection is disabled (the checkboxes don’t work). Only ‘Add for Myself’ is selected. So a plugin installed this way works globally across all projects. But I’m looking for a way to have a separate plugin per project (or for several projects). If the ability to select a project in this menu were unlocked, that would solve the problem!
You’ve got it right, and that’s by design: a plugin in ~/.cursor/plugins/local/ is user-scoped only (it loads into every project), so there’s no per-project toggle for it. Those checkboxes only enable for marketplace-installed plugins.
There’s no single way to get live-editing and per-project today:
Live but global: the local folder you’re on now.
Per-project but pinned: install per-project from a Git marketplace (edits need a reinstall, the friction you already hit).
Per-project + live: use each project’s .cursor/rules / .cursor/skills from one shared source. Note: gitignored .cursor/rules files aren’t picked up, which is why your symlinked ones vanished.
Unlocking per-project selection for a local plugin isn’t possible today.
I don’t have a timeline to share on the local-plugin checkboxes unlocking. We’ll keep tracking this thread to gauge interest.
One thing that gets close today: a project-level workspaceOpen hook can return absolute pluginPaths, so Cursor loads that plugin folder just for that project — live, no reinstall. Keep the real plugin at e.g. ~/cursor-plugins/my-plugin, then add .cursor/hooks.json in each project that should use it pointing to a script that prints those paths. Edits apply on the next reload. If it doesn’t fire, check Cursor Settings → Hooks → Execution Log.
