Summary
On 2.1.271 no skill that lives on disk registers. Neither the 12 user skills in ~/.claude/skills/ nor the skills shipped by an enabled plugin (stripe@claude-plugins-official) appear. The only skills available are the 13 compiled into the binary.
Skill(good-morning) returns Unknown skill: good-morning, and the name never appears in the available-skills list given to the model.
This reproduces in interactive sessions and in claude -p, across restarts.
Environment
Claude Code 2.1.271 (native)
Commit: 3e71603b64bc
Platform: darwin-arm64 (macOS 27.0.0, APFS case-insensitive)
Install: ~/.local/share/claude/versions/2.1.271
claude doctor: "No installation issues found."
Reproduction
$ ls ~/.claude/skills/
brain computer-use good-morning orchestration acme-archive acme-azure
acme-brain acme-repo acme-task acme-wiki standup unlazy
$ claude -p "List every skill name available to you, one per line."
dataviz
update-config
keybindings-help
code-review
simplify
fewer-permission-prompts
loop
schedule
claude-api
workflow-authoring
run
init
security-review
All 13 returned are bundled skills. None of the 12 on disk appear. enabledPlugins contains {"stripe@claude-plugins-official": true} and ~/.claude/plugins/cache/claude-plugins-official/stripe/0.8.2/skills/ exists with 8 SKILL.md files — none of those register either.
What I ruled out
- Directory casing. The directory was
~/.claude/Skills (capital S). Renamed to skills (two-step, case-insensitive FS). No change.
- Symlinks. All 12 entries are symlinks into a work root. I replaced one (
standup) with a real directory (cp -RL) and re-ran: it still did not register. So symlinks alone do not explain it. (Noting 2.1.257's "component path that is a symlink ... now refused" hardening as possibly related, but the real-directory test argues it is not the whole story.)
- Frontmatter.
SKILL.md files parse: name, description (~400 chars), argument-hint, allowed-tools. Same shape as skills that worked previously.
- Org policy.
policy-limits.json restricts only allow_remote_control, allow_quick_web_setup, enforce_web_search_mcp_isolation. Nothing about skills. remote-settings.json is {}.
- Settings. No skill-related key in
~/.claude/settings.json, and none in three dated backups of it.
- Missing plugin install path. The
installPath in installed_plugins.json (0.8.2) exists on disk and contains skills/.
Regression window
These skills worked recently: one of them generates timestamped HTML artifacts, and there are successful runs on disk dated 11, 14 and 15 Sep 2026. By 17 Sep every skill was gone.
2.1.271 was installed 14 Sep, i.e. before the last known-good run, and Last update attempt: none recorded since. So the break does not line up with a version change on this machine — which is why I suspect state or discovery rather than a specific release, and why claude doctor passing is misleading here.
Impact
Every user-authored and plugin-provided skill silently disappears. There is no warning, no count, and no error at startup — the skills simply are not in the list, and invoking one reports Unknown skill, which reads like the file is missing rather than like discovery failed. A startup diagnostic ("found N skill directories, loaded M, skipped K because ...") would have made this a one-minute diagnosis instead of a two-day one.
Possibly the persistent form of #85207, which was reported as a one-off on 2.1.226 where slash commands still worked; here they do not.
Summary
On 2.1.271 no skill that lives on disk registers. Neither the 12 user skills in
~/.claude/skills/nor the skills shipped by an enabled plugin (stripe@claude-plugins-official) appear. The only skills available are the 13 compiled into the binary.Skill(good-morning)returnsUnknown skill: good-morning, and the name never appears in the available-skills list given to the model.This reproduces in interactive sessions and in
claude -p, across restarts.Environment
Reproduction
All 13 returned are bundled skills. None of the 12 on disk appear.
enabledPluginscontains{"stripe@claude-plugins-official": true}and~/.claude/plugins/cache/claude-plugins-official/stripe/0.8.2/skills/exists with 8SKILL.mdfiles — none of those register either.What I ruled out
~/.claude/Skills(capital S). Renamed toskills(two-step, case-insensitive FS). No change.standup) with a real directory (cp -RL) and re-ran: it still did not register. So symlinks alone do not explain it. (Noting 2.1.257's "component path that is a symlink ... now refused" hardening as possibly related, but the real-directory test argues it is not the whole story.)SKILL.mdfiles parse:name,description(~400 chars),argument-hint,allowed-tools. Same shape as skills that worked previously.policy-limits.jsonrestricts onlyallow_remote_control,allow_quick_web_setup,enforce_web_search_mcp_isolation. Nothing about skills.remote-settings.jsonis{}.~/.claude/settings.json, and none in three dated backups of it.installPathininstalled_plugins.json(0.8.2) exists on disk and containsskills/.Regression window
These skills worked recently: one of them generates timestamped HTML artifacts, and there are successful runs on disk dated 11, 14 and 15 Sep 2026. By 17 Sep every skill was gone.
2.1.271 was installed 14 Sep, i.e. before the last known-good run, and
Last update attempt: none recordedsince. So the break does not line up with a version change on this machine — which is why I suspect state or discovery rather than a specific release, and whyclaude doctorpassing is misleading here.Impact
Every user-authored and plugin-provided skill silently disappears. There is no warning, no count, and no error at startup — the skills simply are not in the list, and invoking one reports
Unknown skill, which reads like the file is missing rather than like discovery failed. A startup diagnostic ("found N skill directories, loaded M, skipped K because ...") would have made this a one-minute diagnosis instead of a two-day one.Possibly the persistent form of #85207, which was reported as a one-off on 2.1.226 where slash commands still worked; here they do not.