[BUG] Skill loader selects older plugin cache despite installed_plugins pointing to current version

Open 💬 0 comments Opened Jul 14, 2026 by ramboz

Summary

A newly started Claude Code session loaded a plugin skill from the oldest cached plugin version even though installed_plugins.json pointed to the newest installed version.

The report is public at https://github.com/ramboz/jig/issues/96 and has now reproduced for at least two jig users.

Environment

  • macOS
  • Marketplace plugin: jig@jig
  • Cached plugin versions present: 2.2.0, 2.5.0, 2.7.0
  • installed_plugins.json selected 2.7.0
  • Claude Code version was not captured in the downstream report; I am filing this so the resolver evidence is not lost and will add the exact version if the affected user can recover it.

Steps and observed behavior

  1. Install jig from its marketplace at 2.2.0.
  2. Uninstall or reinstall and update through 2.5.0 to 2.7.0.
  3. Confirm that all three version directories remain under ~/.claude/plugins/cache/jig/jig/.
  4. Confirm that installed_plugins.json points at the 2.7.0 install path and version.
  5. Start a new Claude Code session and invoke the jig:spec-workflow skill.
  6. Observe that the loaded skill base directory resolves to ~/.claude/plugins/cache/jig/jig/2.2.0/skills/spec-workflow/.

The stale skill behavior was externally visible because 2.2.0 contained a known workflow.py transition defect that the current plugin source no longer contained.

Expected behavior

New sessions should load skills from the active install path recorded for the applicable scope. Retained older or orphaned cache directories must not participate in skill resolution.

Actual behavior

The skill loader selected 2.2.0, apparently the lowest version directory, while the installation registry selected 2.7.0.

Workaround

Removing the superseded jig version directories and restarting Claude Code caused the skill loader to resolve 2.7.0 correctly:

rm -rf ~/.claude/plugins/cache/jig/jig/2.2.0 ~/.claude/plugins/cache/jig/jig/2.5.0

This is only a workaround. Claude Code documentation says previous plugin versions are intentionally retained for about seven days so already-running sessions remain valid. The bug is that a new session selects a retained version, not that retained versions exist: https://code.claude.com/docs/en/plugins-reference#plugin-caching-and-file-resolution

Related reports

  • #36569 describes the same skill-resolution failure with a correct installed_plugins.json path and an orphaned old directory; it was closed as stale.
  • #15642 describes stale CLAUDE_PLUGIN_ROOT selection after an update; it was also closed as stale.
  • Downstream reproduction and investigation: https://github.com/ramboz/jig/issues/96

Additional evidence that would help

A resolver debug line naming the selected installation scope, registry entry, and cache path would make this class of failure much easier to diagnose. The affected user can provide the exact Claude Code version and orphan markers if those are still recoverable.

View original on GitHub ↗