[Bug]: Claude skills-directory plugin skills are missing from the `$` picker and mid-message skill rows#23507

opened20d agobyMmikeqwe

Before submitting

I searched existing issues and found the related closed reports below.
I included a minimal layout and the affected versions.

Area

apps/server

Steps to reproduce

Use the Claude provider with a personal skills-directory plugin. For example:
text
1 ~/.claude/skills/demo-wrapper/
2 .claude-plugin/plugin.json {"name":"demo-tools"}
3 skills/
4 review -> /path/to/live/review/
5 SKILL.md
review/SKILL.md is a valid skill. There is no root demo-wrapper/SKILL.md, no marketplace installation, and no installed_plugins.json entry for this plugin. The manifest has the default enablement behavior.
Run claude plugin list --json using the same Claude config directory. The plugin is listed as enabled demo-tools@skills-dir. Claude's initialization inventory contains demo-tools:review.
Start a new Claude thread in T3 Code and open the $ skill picker. Also try the skill rows in the slash menu after other text.

Expected behavior

T3 lists demo-tools:review as a skill, using the manifest namespace and the live SKILL.md path, consistent with the Claude session. This should preserve the existing plugin and source-symlink layout.

Actual behavior

The skill is missing from the $ picker even though Claude loads it. It can reach T3's native slash-command inventory, but not the filesystem-derived skill inventory used for skill rows and $name dispatch.

On main at 680152e27b2a961686389ca69a1557cbb2c55f08, discoverClaudeSkills scans plain skill children and roots from discoverPluginSkillRoots. That helper depends on the installed-plugin registry. Neither discovers an unregistered manifest-bearing plugin inside the skills directory. These source files are unchanged from the affected nightly.

Impact

Major degradation or frequent failure.

Whole namespaced skill sets are unavailable through skill selection. In the observed configuration, 21 qwe and 28 matt skills are native-loaded but missing from this inventory.

Version or commit

T3 Code Nightly 0.1.2-nightly.20261021.3471, source 688ee52f0e8fcc6c0789f82d8145441b6663e7eb. The discovery gap is also present in source at main 680152e27b2a961686389ca69a1557cbb2c55f08.

Environment

macOS desktop Nightly; Claude Code 2.1.306. Personal plugins under the Claude config directory's skills folder; nested skill entries link to live source directories.

Logs or supporting evidence

Native inventory for the actual wrappers:

json

1	[
2	{"id":"matt@skills-dir","scope":"user","enabled":true},
3	{"id":"qwe@skills-dir","scope":"user","enabled":true}
4	]

Claude's raw initialization lists 49 matching namespaced skills/commands. A separate initialize-only fixture confirms that the namespace comes from the manifest, that these plugins default to enabled, and that <name>@skills-dir settings overrides control them.

Official behavior: personal skills-directory plugins, plugin origins and enablement.

Workaround

Partial only. At the very start of the prompt the native command (/qwe:<name>) is still offered, because T3's native slash-command inventory comes from Claude's initialization and contains these names. I have not verified a workaround for the $ picker or for skill rows after other text that keeps this plugin-and-live-symlink layout. One isolated local-marketplace attempt in Claude 2.1.306 copied the plugin to its cache and omitted the external skill links.

This is the remaining skills-directory case called out in the maintainer's reply on #19847, which asks for a new issue for this part only. #5622 and merged #15662 cover installed marketplace plugins; their registry-based fix does not cover @skills-dir plugins.

This reproduction is personal scope. Project plugins have separate workspace-trust rules; this report does not ask T3 to advertise plugins which Claude has not trusted or loaded.

Investigated and drafted with Claude Opus 5.5 (Claude Code) and GPT-6.1-Sol (Codex).