vscode.cursor.plugins.registerPath non-existent

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Cursor AI documentation at https://cursor.com/docs/extension-api#plugin-paths mentions two Cursor API calls for managing custom agent plugin search paths, namely vscode.cursor.plugins.registerPath and vscode.cursor.plugins.unregisterPath. Neither exist.

Steps to Reproduce

Scaffold a basic vscode extension and inspect the vscode API handle while attached to it in the debugger in Cursor AI.

Expected Behavior

The path into the vscode API handle at vscode.cursor.plugins is expected to have two functions named registerPath and unregisterPath, as per the Cursor AI documentation. Neither exist.

Operating System

Windows 10/11

Version Information

Version: 3.3.30 (system setup)
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: editor
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: Windows_NT x64 10.0.26100

Additional Information

I’m running Cursor AI on my Windows desktop but I’m intending to use the extension in a remote Linux dev environment. I’ve tried running an extension in both the Windows and Linux workspace and the problem exists in both.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the report and for digging into the real API via the debugger. This is a docs bug. The extension-api page really describes methods that don’t exist. The actual API is addPlugin / removePlugin, and it takes an object, not a string:

declare module "vscode" {
  export namespace cursor {
    export namespace plugins {
      export interface PluginConfig { path: string; }
      export const addPlugin: (config: PluginConfig) => Thenable<void>;
      export const removePlugin: (config: PluginConfig) => Thenable<void>;
    }
  }
}

// usage
await vscode.cursor.plugins.addPlugin({ path: "/abs/path/to/plugins" });
await vscode.cursor.plugins.removePlugin({ path: "/abs/path/to/plugins" });

The type-stub block on the page is outdated too, it uses the same wrong names. So if you copied it into your project, replace it with the snippet above.

I’ll file a task to fix the docs.

8

Thanks for that information. I did see those functions but didn’t mention them because I don’t want to add/remove specific plugins, which brings me to this statement in the same documentation:

Register additional plugin directories at runtime. Extensions can use this API to tell Cursor about plugin locations without requiring users to manually copy files to ~/.cursor/plugins/local/ .

I took this as meaning that an extension can add additional plugin search paths beyond Cursor’s ~/.cursor/plugins/local path. But maybe my interpretation is wrong.

For testing purposes I have this plugin directory structure:

node@2e7bebf22f7e:~$ pwd
/home/node
node@2e7bebf22f7e:~$ du -a my-plugins
4       my-plugins/my-plugin/skills/my-skill/SKILL.md
8       my-plugins/my-plugin/skills/my-skill
12      my-plugins/my-plugin/skills
4       my-plugins/my-plugin/.cursor-plugin/plugin.json
8       my-plugins/my-plugin/.cursor-plugin
4       my-plugins/my-plugin/mcp.json
28      my-plugins/my-plugin
32      my-plugins

But calling addPlugin({ path: '/home/node/my-plugins' }) then waiting for Cursor to rescan its plugin paths fails to recognise the my-plugin plugin.

If I call addPlugin({ path: '/home/node/my-plugins/my-plugin' }) Cursor recognises the MCP server configuration but not the skill.

As a control test, adding my-plugin to ~/.cursor/plugins/local/ allows Cursor to recognise both the MCP server and the skill.

Would appreciate it if you could clarify how addPlugin is intended to work.

10

The doc wording is genuinely confusing, and there are two separate things here.

  1. addPlugin semantics. It’s for one plugin, not a source directory.

Even though the docs say things like register additional plugin directories and discovers and loads any valid plugins in this directory, the API actually expects the path to the root of a single plugin folder, meaning the folder that contains .cursor-plugin/plugin.json, not a parent folder that contains multiple plugins. You can see that in the signature too, PluginConfig { path: string }, and the name addPlugin is singular. So your second option, /home/node/my-plugins/my-plugin, is the correct usage. The first one, /home/node/my-plugins, won’t work and isn’t supposed to.

Skill discovery inside a plugin is the usual setup: .cursor-plugin/plugin.json plus skills/<name>/SKILL.md, like you have.

  1. The skill not showing up in the UI is a known bug.

Skills added via addPlugin don’t show up in Rules, Skills, Subagents or in the / slash menu, even though the agent can still use them. You can verify this by asking the agent to explicitly use my-skill, it should pick up the SKILL.md file if the frontmatter is correct. MCP servers show up fine because they use a separate pipeline. This issue is being tracked, but I can’t share an ETA for the fix.

We’ll update the docs along with the naming fix, including the addPlugin description and the type stub block.