Local Plugins Symlink on Windows Doesn't Work

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am working on building plugins and releasing to our team marketplace. In order to test locally, I used a symlink as recommended by the docs from my ~/.cursor/plugins/local directory to my repository plugin. I also removed the plugin from my marketplace install and my cache. Cursor would not load the plugin. I tried a junction, which also did not work. The only way to load a local plugin was to manually copy + paste a physical dir for the plugin."

This is contrary to recommendations on the docs (yes I did the symlink in windows command line as well as the junction), and makes developing plugins a bit cumbersome.

Please let me know if you need additional information.

Steps to Reproduce

On Windows 11…

Create a plugin in a chosen directory

Create a symlink from cursor’s user plugin directory to your chosen directory… like:

mklink /D "C:\Users\kaise\.cursor\plugins\local\my-tool" "C:\Code\Serverless\ai-plugin-marketplace\my-tool"

Restart Cursor. Plugin will not be loaded.

Optionally try

cmd.exe /c "mklink /J C:\Users\kaise\.cursor\plugins\local\my-tool C:\Code\Serverless\ai-plugin-marketplace\my-tool"

Reload Cursor. Plugin will not be installed

Expected Behavior

Plugin will be listed under Installed plugins

Operating System

Windows 10/11

Version Information

Version: 3.2.16 (user setup)
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: editor
Build Type: Stable
Release Track: Early Access
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there,
This is a known bug. The local plugin loader currently skips symlinked directories, which contradicts the recommendation in our plugin docs. Both mklink /D (directory symlinks) and mklink /J (junctions) are affected.

Our team is actively working on a fix. For now, the workaround is what you found: copying the plugin directory directly into ~/.cursor/plugins/local/ instead of symlinking.

We’ll update the docs or ship the fix (whichever comes first) so symlinks work as documented. Sorry for the inconvenience, and thanks for reporting this.