[Bug]: Plugin-provided Claude skills (e.g. mattpocock-skills) never appear in the $ picker

Before submitting

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 plugin that ships skills (e.g. mattpocock-skills) and enable it at the project level:

// <project>/.claude/settings.json
{ "enabledPlugins": { "mattpocock-skills@claude-plugins-official": true } }

Open the project in T3 Code (desktop AppImage), start a thread, and type $ in the composer.
Observe: no mattpocock-skills:* entries appear in the picker, even though Claude Code itself lists them.
For comparison, a skill placed under <project>/.claude/skills/<name>/SKILL.md does appear in the picker.

Expected behavior

Skills contributed by enabled plugins should appear in the $ picker alongside filesystem skills, since the engine loads them in the running session.

Actual behavior

Plugin-provided skills are never listed. The $ picker is fed from the provider snapshot's skills field, which discoverClaudeSkills (apps/server/src/provider/Drivers/ClaudeSkills.ts, ~L102) builds by scanning only two filesystem roots:

const roots = [
  { directory: path.join(configDirPath, "skills"), scope: "user" },
  ...(cwd ? [{ directory: path.join(cwd, ".claude", "skills"), scope: "project" as const }] : []),
];

Neither root covers the plugin cache, so ~/.claude/plugins/cache/claude-plugins-official/mattpocock-skills/1.2.3/skills/** is invisible to the picker.

This is picker/discovery-only: the skill is still fully invocable by name. I captured the provider init handshake for a thread with the plugin enabled and it lists mattpocock-skills:grill-with-docs (and all other plugin skills) in the model's loaded skills, with the Skill tool present. So the engine has them; only T3's filesystem inventory misses them.

Impact

Minor bug or occasional failure

Version or commit

0.0.32-nightly.20260807.1023 (desktop AppImage), Linux x64

Environment

Ubuntu (kernel 7.0.0), T3 Code desktop AppImage 0.0.32-nightly.20260807.1023, Claude provider (claude-agent-sdk 0.3.223), mattpocock-skills 1.2.3

Logs or stack traces

Provider init handshake (session claude/system/init, trimmed to the relevant fields):

{
  "skills": [ "mattpocock-skills:grill-with-docs", "mattpocock-skills:tdd", "..." ],
  "tools": [ "Skill", "..." ]
}

Workaround

Invoke plugin skills by name in prose ("use grill-with-docs on this") rather than via the $ picker — the model resolves and runs them. Picker-based discovery for plugin skills is unavailable.

Notes

Same underlying discovery limitation as #4544 (packaged desktop, project-level skills) and #5487 (.agents/skills root), but specifically for plugin-contributed skills. PR #5488 proposes adding a .agents/skills scan root; plugin skills would need a third source (the enabled plugin cache dirs) or surfacing the SDK init skill list into the snapshot instead of filesystem-only discovery.

If you're running the web interface via npx t3@... then the skills in the repo will appear with the $ picker so long as you run npx in the project root folder. What then does, however, seem to be a bug is if you move to another project, the skills from project A are still available (this seems like a mess to keep track of - T3 Code is mainly motivated to move between projects with ease, so it suggests that project-level skills are less favoured than user-level skills available to all projects).

Two additions after re-reading this on main @ ad11723.

1. The roots list in the description is now stale. discoverClaudeSkills scans three roots today, not two — <cwd>/.agents/skills landed via #5488 (ClaudeSkills.ts:104-112), with precedence user < .agents < .claude. The plugin gap this issue reports is unchanged.

2. The same gap also hides plugin slash commands, not just the $ picker. Plugins enabled at user scope appear under /; plugins enabled in a project's .claude/settings.json never do. The capability probe reads its setting sources relative to the wrong directory:

ClaudeDriver.ts:124 takes cwd from ServerConfig — the server's startup directory, fixed for the process lifetime.
That cwd is passed to probeClaudeCapabilities (ClaudeDriver.ts:160), whose options keep settingSources: ["user", "project", "local"] (CLAUDE_CAPABILITIES_PROBE_SETTING_SOURCES in ClaudeProvider.ts) specifically for slash-command discovery.
So the whole project settings layer — including enabledPlugins — is read from the server's directory. <project>/.claude/settings.json is never opened, and the / list carries only user-scope plugins.

That is the same defect #6449 describes for $, reaching a second menu through a different code path. It means a complete fix for plugin skills needs both #6453 (the plugin roots) and the cwd work (#6449 / #6450 / #6661) — #6453 alone still leaves project-enabled plugins invisible in both menus.

As this issue already notes, the runtime is unaffected: the real session gets the correct project cwd, so the skills do work when invoked. Only the menus are wrong.

Still reproduces on nightly 0.0.43-nightly.20260926.2282 (6530de0339d2), macOS, for the / menu with a plugin enabled only in <project>/.claude/settings.json. The skills run when the full /plugin:skill is typed, but the menu never lists them. The bundle still passes the ServerConfig cwd to probeClaudeCapabilities, and discoverClaudeSkills still scans only ~/.claude/skills and <cwd>/.claude/skills, so project-enabled plugins stay hidden. The related fixes (#6450, #6453, #6661) are closed, so this issue is the remaining place to track it.

same - please fix it

chore: add install-flat script as T3 Code workaround

Also seeing this on T3 Code v0.0.45, macOS arm64, using the Claude Code provider. Global and project skills appear in the slash-command menu, but plugin-provided skills do not.

Our team uses Claude Code plugins to distribute and update shared skills. Missing plugin skills in the picker makes those workflows harder to discover and use within T3. Plugin skill discovery would let us retain that distribution workflow.

Prepared through T3 triage by Codex (GPT-6).

I'm running into this too.

Switching to a GPT model enables the skill, but when I switch to a Claude model that installed same skill as a plugin, it cannot discover it most of the time.

Another data point (T3 0.0.46 nightly, Linux, Claude provider). $implement-spec reached Claude as literal text in four sessions, while Codex threads loaded the same skill. The skill exists both as a plugin skill (mattpocock-skills:implement-spec) and in the user-level ~/.agents/skills/implement-spec. So besides plugins, the user-level ~/.agents/skills root also seems to be missing from Claude discovery: the roots listed above include <cwd>/.agents/skills but not ~/.agents/skills. The composer still shows it as a chip (#14656), so the prompt looks invoked when it isn't. Workaround: a UserPromptSubmit hook that injects the matching SKILL.md, or a symlink into ~/.claude/skills.

Navigation Menu

Repository navigation

[Bug]: Plugin-provided Claude skills (e.g. mattpocock-skills) never appear in the `$` picker #5622

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Workaround

Notes

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Plugin-provided Claude skills (e.g. mattpocock-skills) never appear in the $ picker #5622

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Workaround

Notes

Activity

mrdowdeswell commented on Aug 11, 2026

hodeinavarro commented on Aug 15, 2026

17 remaining items

schovi commented on Sep 27, 2026

vltansky commented on Sep 29, 2026

rama-adi commented on Oct 6, 2026

jinsley8 commented on Oct 8, 2026

amihos commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]: Plugin-provided Claude skills (e.g. mattpocock-skills) never appear in the `$` picker #5622