Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Summary
Skills bundled inside plugins are loaded by the plugin subsystem but never reach the agent’s skill registry in the headless cursor-agent CLI. The IDE agent surfaces plugin skills from the official Cursor Marketplace, but the CLI does not — not from Cursor marketplace plugins, not from local plugins (~/.cursor/plugins/local/), and not from Claude Code marketplace plugins. Skills only register when placed directly in one of four well-known paths. This breaks the value proposition of plugin-based skill distribution for any workflow that uses the CLI (CI, evals, headless agents).
Request ID / Privacy note
Our Cursor Enterprise admin policy enforces Privacy Mode, so I cannot enable Share Data to produce a content-visible Request ID. This bug is deterministic and reproducible on any machine via the minimal canary case below — the Cursor team should not need session content to reproduce it.
For completeness, these are the cursor-agent CLI session_ids from my test runs (metadata-level visibility only):
| Behavior | session_id |
|---|---|
| Plugin skill not surfaced (Claude Code install) | c1c57a65-76df-43ec-a50f-9e5da6f63cd6 |
| Skill enumeration — plugins absent | ffad3026-6565-4690-ba98-303cab03b386 |
Skill fires from ~/.cursor/skills/ (control) |
98dead3b-504b-4f5c-b2d9-21eafe48ba9e |
Skill fires via symlink into ~/.cursor/skills/ |
3ffbf1cf-225d-495c-8ada-8c30875acfd3 |
Happy to coordinate through our Enterprise account rep if more detailed evidence is needed — please reach out if that’s the preferred channel for this class of issue.
What actually happens
The plugin loader logs success, but the agent has zero knowledge of the skill’s content. When asked to enumerate available skills, the CLI returns only skills from:
<repo>/.claude/skills/<repo>/.cursor/skills/~/.cursor/skills/~/.cursor/skills-cursor/
Plugin skill paths are never returned, regardless of whether the plugin is:
| Source | IDE registers skills? | CLI registers skills? |
|---|---|---|
Cursor public marketplace (~/.cursor/plugins/cache/cursor-public/*/skills/) |
 |
 |
Cursor local plugin (~/.cursor/plugins/local/*/skills/) |
(likely yes, untested) | |
Claude Code marketplace (~/.claude/plugins/cache/*/*/skills/) |
|
|
Workaround currently in use
Symlinking plugin skill directories into ~/.cursor/skills/:
ln -s \
~/.claude/plugins/cache/<marketplace>/<plugin>/<sha>/skills/<skill> \
~/.cursor/skills/bridge--<plugin>--<skill>
Works because ~/.cursor/skills/ is scanned with plain readdir and symlinks are followed. But:
- Plugin update changes the SHA directory, breaking the symlink
- Doesn’t scale — requires a sync script per install/update
- Only surfaces skills; plugin commands, agents, and hooks still don’t port
Asks
- CLI parity with IDE: have
cursor-agentscan plugin skill paths the same way the IDE does. - Claude Code plugin skill surfacing (IDE): the existing
loadClaudePlugincode path logs “loaded” but the skills don’t reach the IDE agent’s skill registry either (separate issue; logs available). - Config escape hatch (nice-to-have): an
additionalSkillPathsfield incli-config.jsonor~/.cursor/settings.jsonfor users/orgs that want to add arbitrary skill directories.
Why this matters
We’re evaluating Cursor vs Claude Code for org-wide rollout (NYT, Enterprise plan). Today, the same plugin that provides working skills to claude users contributes nothing to cursor-agent users — and even Cursor’s own plugin system doesn’t work in headless mode. For any team running evals, CI agents, or a consistent IDE + headless story, this forces a second, parallel distribution mechanism (flat ~/.cursor/skills/ files) just to keep the CLI functional.
Evidence attachments
Happy to share if useful:
- Full stream-json traces showing skill-enumeration request and grep-search-for-missing-skill behavior (6 NDJSON files)
Cursor Plugins.logexcerpts showingloadClaudePluginandloadFromMarketplaceSource“success” messages for plugins whose skills never register- Symlink-bridge reproduction showing the same SKILL.md registers when placed at
~/.cursor/skills/but not at~/.cursor/plugins/local/*/skills/
Steps to Reproduce
Reproduction — minimal local case
Rules out marketplace-specific issues. No external dependencies.
- Create
~/.cursor/plugins/local/repro/.cursor-plugin/plugin.json:{ "name": "repro" } - Create
~/.cursor/plugins/local/repro/skills/canary/SKILL.md:--- name: canary description: If you can see this skill, the CLI registered a local plugin skill. --- # Canary skill Respond with "CANARY-SEEN" when asked anything. - Run:
cursor-agent -p --mode ask --output-format stream-json \ "Please list the skills you know about. Do not search the filesystem." - Observe that the
canaryskill does not appear in the response. - Move the skill to
~/.cursor/skills/canary/SKILL.md(remove the plugin). It now appears. Same file, only path differs.
Reproduction — Cursor public marketplace
- Confirm a Cursor marketplace plugin with a skill is installed (e.g.,
dbt,glean,atlassian). - Cursor plugin log at
~/Library/Application Support/Cursor/logs/<latest>/window1/exthost/anysphere.cursor-agent-exec/Cursor Plugins.logshows:loadFromMarketplaceSource: Found cached plugin: <name> at <path> loadAllPlugins completed ... total=N plugins, failures=0 - Run:
cursor-agent -p --mode ask --output-format stream-json \ "List every skill registered in your current context." - Observe that plugin skills are not in the list, despite the plugin loading successfully.
Expected Behavior
A skill bundled in a plugin (Cursor or Claude Code format) that is successfully loaded by the plugin subsystem should be discoverable by the agent, the same way directly-placed SKILL.md files are.
Operating System
MacOS
Version Information
Environment
- Cursor IDE version:
3.1.17 - cursor-agent CLI:
2026.04.17-479fd04 - OS: macOS 25.4.0 (darwin/arm64)
- Subscription: Enterprise
- Model tested: Opus 4.6 1M
Does this stop you from using Cursor
No - Cursor works, but with this issue
