[FEATURE] Cloud-shared skills load as a plugin and never reload mid-session — restart required after every update

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Skills from the cloud Skills store — my own updates and skills shared with me — never refresh in a running session. The only way to pick up a new version is to quit and reopen Claude Code, or start a new session and lose all context.

I author ~45 skills and update them almost daily, sharing them with a consulting team. Every single edit costs a restart. Any session that doesn't restart silently keeps running the previous version.

Why this isn't already covered by "skills hot-reload." The docs say skill changes are picked up in-session, and a whole generation of reload requests was closed on that basis (#14314, #20507, #23385, #28685, #29202, #38707). That's true — for ~/.claude/skills/, a project .claude/skills/, and --add-dir skills dirs. Cloud/shared skills are not loaded through that path at all.

They arrive as a plugin. On macOS:

~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/<uuid>/<uuid>/
├── .claude-plugin/plugin.json   → { "name": "anthropic-skills", "version": "1.0.0", ... }
├── manifest.json
└── skills/                       → 45 skill dirs

and the session is launched with --plugin-dir pointing at it. So cloud skills inherit plugin reload semantics, not skill semantics — and nothing in the product or docs surfaces that distinction. From the user's side it looks like "skills hot-reload, except mine, unpredictably."

The staleness signal already exists on disk and nothing consumes it. manifest.json carries a top-level lastUpdated epoch plus, per skill, updatedAt and enabled:

{ "lastUpdated": 1785447884153,
  "skills": [ { "skillId": "...", "name": "...", "updatedAt": "2026-07-30T17:58:17.742726Z", "enabled": true }, ... ] }

And the sync does write during a live session — I watched the plugin directory's mtime move while a session was running, with individual skill dirs stamped the same day. The updated bytes are sitting on disk; the running session just never looks again.

Two distinct costs, and the second is worse:

1. Authors restart once per iteration. Edit → upload → quit → reopen → re-establish context → test → find the next issue → repeat. Updating daily means restarting daily, and each restart throws away the conversation I was debugging in.
2. Recipients have no idea they're stale. I publish a fix; my colleagues keep running the broken version indefinitely, because their sessions predate it and nothing tells them. There's no notification, no indicator, no way for them to know a skill they're relying on was corrected hours ago. They only get the fix when they happen to restart for an unrelated reason.

The second one is a correctness problem, not an ergonomics one — people execute stale procedures believing they're current.

Proposed Solution

Treat the cloud skills-plugin manifest as a live input: when it changes on disk, refresh the loaded skills in-session — the same way local .claude/skills/ already works.

1. Re-read manifest.json when its mtime changes and reload skills whose updatedAt moved, add ones newly present, drop ones removed or enabled: false. The timestamps are already there, so this is a cheap check rather than a rescan of 45 directories. A natural hook point is before each query, exactly as proposed for MCP in #24057.

1. At minimum, make /reload-skills actually cover cloud-shared skills — and document which path it applies to. Right now it isn't clear to users that cloud skills are a different mechanism from local ones, so "there's a reload command" reads as solved when it isn't for this case.

1. Surface staleness even if reload stays manual. If the on-disk manifest is newer than what the session loaded, say so — a line in /status, or a note when a stale skill is invoked. Silently executing an outdated procedure is the failure mode with real consequences, and it's cheap to detect given lastUpdated.

1. Notify recipients when a shared skill they use is updated. Authors know they published; recipients currently have no signal at all. Even a passive indicator would close the loop.

Priority order, if only one lands: #3 first — detection and honesty about staleness is small and removes the silent-wrong-version class entirely. #1 is the real fix.

Environment: Claude Code 2.1.219 (Claude Desktop), macOS 26.5.2 (Darwin 25.5.0). ~45 skills in the anthropic-skills cloud plugin.

Related:

• #24057 — MCP/hooks/plugins should auto-reload (open, 19 👍). Titled to include plugins, but the discussion is almost entirely MCP servers. This is the plugin half, and specifically the cloud-skills-delivered-as-a-plugin case, which nobody there has raised. Happy for these to be merged if maintainers see them as one.
• #37915 — plugin/skill auto-update check before execution (open)
• #82677 — org skills not syncing to CLI (open) — possibly the same family
• Closed as "skills already hot-reload": #14314, #20507, #23385, #28685, #29202, #38707. All concern local skill directories and none cover the cloud/shared path.

Alternative Solutions

Restarting after every update. This is what I actually do, and it's why I can state the behavior confidently rather than guessing: every time I don't restart, the session uses the old skill. A resumed session does pick up changes — which makes the behavior look intermittent from the outside, since an app restart that resumes the same conversation reads the plugin dir again. That resume-based refresh is the only thing that works today, and it still requires quitting the app.

Starting a new session instead. Same result, and it discards the conversation — which for long debugging sessions is the expensive part. When the whole point of the skill edit is to fix something I'm mid-way through testing, losing that context defeats the exercise.

Editing the plugin cache on disk directly (skills-plugin/<uuid>/<uuid>/skills/...) to skip the upload round-trip. Fragile: it's a cache, the sync overwrites it, the UUID paths aren't stable to script against, and critically it does nothing for the people I share with — their copies are unaffected.

Keeping a duplicate of each skill in ~/.claude/skills/ so the local hot-reload path picks it up. Would work for me alone, and it's the closest thing to a real workaround. But it means maintaining two copies of 45 skills and keeping them in sync by hand, and it still leaves every recipient on the stale cloud copy — which is the half that actually matters.

/reload-skills / /reload-plugins. I haven't been able to confirm either reliably picks up cloud-store changes mid-session; my experience is that a restart is what works. If one of them is supposed to cover this path, that's a documentation gap in itself — nothing indicates cloud skills are a different mechanism from local ones.

None of these help recipients, which is the part I can't solve on my own from the authoring side.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Scenario A — iterating on a skill (the author's cost).

1. I'm deep in a session debugging a deploy problem. I realize the deploy skill has a wrong step.
2. I edit the skill and upload the new version. The bytes land on disk — I can watch the plugin dir mtime move.
3. The session I'm in keeps using the old version. Nothing indicates why.
4. To test my fix I quit Claude Code and reopen. The session resumes and now has the new skill.
5. I test. There's a second problem. Back to step 2.

Updating almost daily means restarting almost daily, often several times, and each restart interrupts whatever I was actually working on. The edit-test loop for a skill is bounded by app restarts rather than by how fast I can write the fix.

Scenario B — a stale skill in someone else's hands (the one that actually hurts).

1. 9:00am — a colleague reports that my deploy skill fails; a server path changed.
2. 9:10am — I fix it and publish. As far as I'm concerned, that's done and the team is covered.
3. All day — three colleagues run that skill in sessions that started before 9:10. They all get the old, broken version. No warning, no indicator, no notification. From their side the skill is simply still broken, and from mine it's fixed.
4. One of them assumes the skill is just unreliable and does the deploy by hand — the exact failure mode the skill exists to prevent.
5. They get the fix whenever they next happen to restart for some unrelated reason. Could be that afternoon; could be next week.

The gap between "published" and "in effect" is unbounded and invisible to both sides. With the manifest already carrying lastUpdated and per-skill updatedAt, even just detecting and reporting the mismatch would eliminate the silent-wrong-version case — and a proper in-session reload would eliminate the wait entirely.

Additional Context

_No response_