You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Cursor plugin skills are missing from the composer and from the agent catalog #16408
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Install a Cursor plugin that ships one or more skills. A marketplace plugin, a team plugin, or a local plugin under ~/.cursor/plugins/local is enough. Confirm those skills appear in Cursor Customize and can be invoked with /skill-name.
Open a Cursor thread in T3 Code Nightly on a project.
Open the $ skill picker.
Ask the Cursor agent, without letting it read the filesystem, which skills are in its catalog. Ask specifically about the skill names from that plugin.
Expected behavior
Skills from enabled Cursor plugins show up in the $ picker and are part of the agent's skill catalog, the same way skills in ~/.agents/skills and ~/.cursor/skills are. $skill-name is sent as /skill-name.
Actual behavior
The picker only scans .cursor/skills, .agents/skills, .codex/skills, and .claude/skills (apps/server/src/provider/Drivers/CursorSkills.ts). Plugin skills live under ~/.cursor/plugins/cache/<marketplace>/<plugin>/<sha>/skills/ and never enter that list.
The agent catalog has the same hole. A Grok 4.6 Cursor thread listed the built-in Cursor skills and the folder skills, and reported that the plugin skills were not present. makeCursorAgentOptions does pass settingSources: ["project", "user", "team", "mdm", "plugins"] (from #13499), and the SDK has a CursorPluginsAgentSkillsService that loads enabled plugin skills, but those skills are not in the catalog the model receives.
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261005.2702
Environment
macOS, T3 Code Nightly, Cursor provider (Cursor V2 / @cursor/sdk 1.0.35). Confirmed with Grok 4.6 and Grok 4.7.
Logs or stack traces
None.
Workaround
Copy or symlink each plugin skill directory into ~/.cursor/skills or ~/.agents/skills. Those roots are both scanned by T3 and loaded by the SDK.
Thanks @Melv1C for the thorough write-up, the paths and the workaround made this quick to trace.
What I found
Composer ($ picker): this reproduces on current main. inspectCursorSkills in apps/server/src/provider/Drivers/CursorSkills.ts only walks .cursor/skills, .agents/skills, .codex/skills, and .claude/skills under the project and home directory. Plugin skills live outside those roots (~/.cursor/plugins/local/<plugin>/skills and ~/.cursor/plugins/cache/<marketplace>/<plugin>/<sha>/skills), so they never reach the picker. CursorAdapterV2 rewrites $skill-name to /skill-name from that same list, so plugin skills can't be invoked from the composer either. That's why copying or symlinking into ~/.cursor/skills / ~/.agents/skills works. fix(claude): discover enabled installed plugin skills #15662 covers the equivalent gap for Claude only.
Agent catalog: this looks like a different mechanism. makeCursorAgentOptions passes settingSources: [..., "plugins"] (fix(server): Cursor V2 threads load project skills and rules #13499), and in @cursor/sdk 1.0.35 that does construct CursorPluginsAgentSkillsService, whose skills are merged into getAgentSkills and sent as requestContext.agentSkills. With the options T3 passes:
user-local plugins under ~/.cursor/plugins/local are loaded, including their skills/ directory;
marketplace and team plugins are resolved only when the session has an API key (via getEffectiveUserPlugins); the on-disk plugins/cache tree isn't scanned by itself;
importThirdPartyPlugins stays at the SDK default false, so claude-plugin-sourced plugins are filtered out.
So a marketplace, team, or Claude plugin missing from the model's catalog could come from that wiring, while a missing user-local plugin wouldn't match what 1.0.35 does. If you're seeing a local plugin missing, the plugin directory name and whether the Cursor session inside T3 was signed in would help tell the two apart.
Likely fix area
Some options:
Extend CursorSkills.ts to also discover skills from enabled Cursor plugins (local plugins, and the marketplace/team cache, ideally limited to enabled plugins and the active <sha>), so the picker and the $ → / rewrite include them.
For the catalog side, look at how T3 configures the SDK session (API key availability for marketplace/team plugin resolution, and whether importThirdPartyPlugins should be set).
Activity
juliusmarminge commentedon Oct 6, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @Melv1C for the thorough write-up, the paths and the workaround made this quick to trace.
What I found
Composer (
$picker): this reproduces on currentmain.inspectCursorSkillsinapps/server/src/provider/Drivers/CursorSkills.tsonly walks.cursor/skills,.agents/skills,.codex/skills, and.claude/skillsunder the project and home directory. Plugin skills live outside those roots (~/.cursor/plugins/local/<plugin>/skillsand~/.cursor/plugins/cache/<marketplace>/<plugin>/<sha>/skills), so they never reach the picker.CursorAdapterV2rewrites$skill-nameto/skill-namefrom that same list, so plugin skills can't be invoked from the composer either. That's why copying or symlinking into~/.cursor/skills/~/.agents/skillsworks. fix(claude): discover enabled installed plugin skills #15662 covers the equivalent gap for Claude only.Agent catalog: this looks like a different mechanism.
makeCursorAgentOptionspassessettingSources: [..., "plugins"](fix(server): Cursor V2 threads load project skills and rules #13499), and in@cursor/sdk1.0.35 that does constructCursorPluginsAgentSkillsService, whose skills are merged intogetAgentSkillsand sent asrequestContext.agentSkills. With the options T3 passes:~/.cursor/plugins/localare loaded, including theirskills/directory;getEffectiveUserPlugins); the on-diskplugins/cachetree isn't scanned by itself;importThirdPartyPluginsstays at the SDK defaultfalse, soclaude-plugin-sourced plugins are filtered out.So a marketplace, team, or Claude plugin missing from the model's catalog could come from that wiring, while a missing user-local plugin wouldn't match what 1.0.35 does. If you're seeing a local plugin missing, the plugin directory name and whether the Cursor session inside T3 was signed in would help tell the two apart.
Likely fix area
Some options:
CursorSkills.tsto also discover skills from enabled Cursor plugins (local plugins, and the marketplace/team cache, ideally limited to enabled plugins and the active<sha>), so the picker and the$→/rewrite include them.importThirdPartyPluginsshould be set).A maintainer will decide on the fix direction.
test(provider-cursor): Cursor plugin skills reach the skill list