[BUG] Claude can't see your skills: `/skills` says they're loaded, but the listing reaches the model late or never (2.1.295)

Status Open

Reported on v2.1.295

Maintainer reply None cached

Activity 3 comments · opened Oct 9, 2026

Summary

In an ordinary interactive CLI session, the main agent never receives the available-skills listing, while /skills and /context show the skills as enabled and loaded. A subagent spawned from the same session does get the full listing.

Because the Skill tool tells the model to "only use names from the listing", the main agent can't find user skills and quietly falls back to generic tools. In my case the user had a skill built specifically for X/Twitter links, and its description says to use it whenever the user pastes an X link. The agent opened the link with a generic MCP scraper instead.

This looks like the same root cause as #87281 (background-job main session missing the skills listing), but it is not limited to background jobs. It also resembles #74990 (listing dropped after compaction), but no compaction happened: the session used about 5% of its context.

Environment

Claude Code 2.1.295
macOS 26.7.1 (darwin 25.6.0), Apple Silicon, zsh
Model: claude-opus-5-5 (1M context)
Interactive terminal session, auto mode, home directory as cwd (not a git repo)
6 personal skills in ~/.claude/skills/, each with valid frontmatter, plus 1 plugin skill and the built-ins
Several MCP servers connected (firecrawl, exa, context7, deepwiki, claude-code-docs)

What the UI says

/skills → "No changes". The dialog lists 7 skills, all ✔ enabled:

✔ typesafe:typesafe-ai   locked by plugin · plugin · ~230 tok
✔ drift-check            user · ~120 tok
✔ gitnexus-graph         user · ~190 tok
✔ mitmproxy              user · ~110 tok
✔ move-project           user · ~100 tok
✔ scripted-video         user · ~130 tok
✔ x-search               user · ~140 tok

/context counts Skills: 3.3k tokens (0.3%) and lists all 6 user skills, the plugin skill and 15 built-ins as loaded.

What the main agent actually received

Asked to check its own context, the main agent reported these system-reminders/sections: the userEmail context, git attribution, environment, the deferred-tools list, the agent-types listing and MCP server instructions. No skills listing. It only found the skill by running ls ~/.claude/skills/, after the user complained.

What a subagent from the same session received

The main agent spawned a general-purpose subagent with no tools allowed and asked it to report any skills listing verbatim. It reported a block starting The following skills are available for use with the Skill tool: that contains all 22 skills, matching /context exactly (drift-check, gitnexus-graph, mitmproxy, move-project, scripted-video, x-search, typesafe:typesafe-ai, dataviz, artifact-design, …, security-review).

Interestingly, the visibility is inverted between the two:

| | skills listing | agent-types listing |
|---|---|---|
| main session | ❌ missing | ✅ present |
| subagent | ✅ present | ❌ missing |

Repro

Put one or more personal skills in ~/.claude/skills/<name>/SKILL.md with valid name/description frontmatter (e.g. a skill whose description says "use whenever the user pastes an x.com link").
Have one or more MCP servers configured (mine: firecrawl, exa, context7, deepwiki, claude-code-docs).
Start a fresh interactive claude session and send a first prompt that matches the skill (e.g. paste an x.com link and ask a question about it).
Observe: the agent uses a generic tool instead of the skill.
Run /skills and /context: both show the skill as enabled and loaded.
Ask the agent: "Without using tools, is there a list of available skills in your context? List the names verbatim." → it reports none.
Ask the agent to spawn a subagent with the same no-tools question → the subagent lists all skills.

I haven't isolated which part of the setup triggers it (MCP servers, auto mode, plugin skills or cwd = home). It happened on the first turn of a fresh session.

Expected

The main interactive session gets the same skills listing that /context counts and that subagents receive. Or, if the listing really is missing, /context and /skills shouldn't report the skills as loaded.

Impact

The failure is silent. The UI tells the user their skills are active, the agent honestly doesn't know they exist, and the user ends up thinking the agent is ignoring their tools on purpose.

View original on GitHub ↗

3 Comments

voidfreud · 5 days ago

Suggestion: a session-start capability check / manifest checklist

I think this is bigger than skills alone. On earlier versions I saw the same thing with MCP servers: config and the UI showed one state, but the model actually got something else. The files and settings say a capability is loaded, the model never receives the block, and nothing anywhere flags the mismatch.

The result is a session that's broken from the first turn. The model makes mistakes it can't avoid, like ignoring tools it was never told about, and the user reasonably reads that as the model misbehaving rather than the harness failing to deliver context.

What I'd suggest:

Build an expected-context manifest at session start. From settings and files on disk, list what should be in the model's context: skills listing, MCP server instructions and tools, deferred-tools list, agent types, CLAUDE.md / memory, hooks output, etc.
Check it against what was actually sent. After assembling the first request (and after compaction, /rewind, resume, background-job start and subagent spawn), confirm each expected block is really in the payload and isn't empty.
Warn when something's missing. Show a visible warning in the TUI, e.g. ⚠ skills listing expected (22 skills) but not delivered to the model. Optionally offer a one-key re-inject or reload.
Make /context show what was delivered, not what was configured. Right now /context and /skills report the configured state, which is exactly why this bug is invisible to users. Even a "delivered: yes/no" marker per category would have caught this immediately.

None of this would stop the underlying bug, but it would turn a silent, confusing failure into a clear warning at session start. I can approximate this locally with my own modifications (mods), but it really belongs in the harness. Given how many related reports there are (#87281, #74990, #85455, #94776), this looks like a whole class of context-delivery bugs rather than a one-off, and in my opinion a substantial one.

voidfreud · 5 days ago

Second repro on 2.1.295: the listing arrives late, not never

Same setup as the original report: 2.1.295 (the current npm release), macOS, auto mode, cwd = ~, same MCP servers. The first prompt was a skill-trigger case ("use x skill", meant for my x-search skill).

Timeline in that session:

Turn 1: the context had the environment block, deferred-tools list, agent-type listing and MCP server instructions, but no skills listing. The agent guessed Skill("x").
The Skill tool knew about the skills already. Skill("x") returned Unknown skill: x. Did you mean cd? The registry is clearly loaded, since the tool validates names against it, but the listing reminder wasn't sent. cd also isn't the name of any skill or command I have, so the "did you mean" matcher seems to check a different list from the one /skills and /context show.
Turns 2 and 3: /context and /context all both showed 22 skills (3.3k tokens), and the agent still had no listing.
Turn 4, mid-turn: after a batch of Bash (gh) tool calls returned, the full The following skills are available for use with the Skill tool: reminder suddenly appeared with all 22 skills. Nothing skill-related happened right before it.
Turn 5: after I ran /reload-plugins, the listing was delivered again.

So the listing isn't always missing for the whole session. It's held back for several turns and then sent at an unpredictable point. That looks like the same mechanism as #94776, where the agent-type listing isn't sent on turn 1 and only arrives once some later condition is met.

Related issues (same class: a listing or context block that isn't delivered to the model)

#94776: the initial agent-type listing isn't sent on turn 1 and arrives 2 to 49 turns later. It's the closest match to the delayed delivery above.
#87281: background-job main sessions never get the skills listing, while their subagents do. Same main/subagent inversion as this issue.
#98513: documents where the skills listing sits in the first request (a system block after the first user prompt), which is where it was missing here.
#98895: auto-compaction drops the entire skills listing (2.1.281). It's a refiled version of #74990.
#74990: /compact and auto-compaction drop the skills listing. The bot closed it without a fix.
#85455: /rewind to before the first prompt drops the skills listing.
#95367: in 2.1.271, no skills from disk loaded at all. That was a harder failure of the same pipeline.
#98223: Unknown skill for one specific skill while sibling skills work. This may be related to the name-matching mismatch in point 2.

I don't think this is specific to 2.1.295. The same class of bug has been reported since at least 2.1.226 and 2.1.233.

marcindulak · 3 days ago

Please note that this issue is on its way to be auto-closed.

To prevent this issue from getting stale, you would need to collect at least 10 thumbs up or comment every time before the 14 days interval expires. See https://github.com/anthropics/claude-code/issues/87647 for more details and consider upvoting that for visibility.