Plugin agents/ intermittently fail to register while the same plugin's skills/ load normally (2.1.220)

Summary

On Claude Code 2.1.220, a session loaded a plugin's skills/ normally but registered none of that plugin's agents/. Every plugin:agent value for subagent_type was unresolvable for the life of the session, while the same plugin's skills were fully available in the same session.

Two sessions on the same machine, same config profile, same 2.1.220 build, same day, with the same plugins enabled. One registered all 14 plugin agents. The other registered zero. The only difference I can identify is the working directory the session was opened in.

What the failure looks like

An Agent dispatch to a plugin-provided type fails with:

Agent type 'my-plugin:some-reviewer' not found.
Available agents: my-user-level-agent, claude, claude-code-guide, Explore,
                  general-purpose, Plan, statusline-setup

The available-agents list is the diagnostic part. It contains:

• the built-in agent types, and
• exactly one user-level agent definition

and zero agents from any plugin — not just the plugin that was asked for, but every enabled plugin. In the healthy session the same error (triggered deliberately with a nonexistent type) enumerates all 14 plugin agents alongside the built-ins.

So user-level agent definitions propagated and plugin agents/ did not, in a session where plugin skills/ propagated fine.

What I ruled out

| Hypothesis | Why it does not explain it |
|---|---|
| Plugin not enabled | Both plugins are true under enabledPlugins in both settings files that could apply; the directory the failing session ran in sets no enabledPlugins at all |
| Agent files missing from the cache | All 14 agent definition files were present in the loaded plugin cache directory at the time |
| Plugin discovery failed | The same plugins' full skill roster loaded normally in the failing session |
| Version skew | Both sessions report the same 2.1.220 build |
| Nested/subagent context | The failing session was a normal top-level interactive session |
| Wrong type name | The names were correct; the same names resolve in the healthy session |

Reproduction

I have not found a way to force it — it appears intermittent, and both sessions were configured identically. The observation is:

1. Open a session in directory A. Ask for the list of available agent types (or dispatch to a deliberately nonexistent subagent_type and read the enumerated roster from the error).
2. Open a session in directory B, same machine, same profile, same enabled plugins. Repeat.
3. Compare the two rosters.

In my case directory A produced a roster containing only built-ins plus one user-level agent; directory B produced the same roster plus all 14 plugin agents.

If there is a log or diagnostic that records plugin agent registration specifically — as distinct from plugin skill registration — I am happy to capture it on the next occurrence and attach it.

Why it matters

Workflows that dispatch to named plugin agents lose the whole roster at once, silently, in a session that otherwise looks completely healthy. Because the plugin's skills still load, nothing else about the session suggests a plugin problem, and the natural read of the error is "the plugin is not installed" — which is wrong and sends the user to the wrong fix.

The error string is also shared with an unrelated naming mistake (asking for a type under the wrong name), so the only way to tell the two apart is to read whether the enumerated roster contains plugin agents. That works, but it is an inference from an error message rather than a supported signal.

Two things that would help regardless of the root cause:

1. A way to distinguish "this type does not exist" from "no plugin agents registered in this session" — even just a note in the error when the plugin agent set is empty but plugins are loaded.
2. A documented statement of whether plugin skills/ and plugin agents/ are expected to register atomically. If they are, this is a bug; if they are not, that is worth knowing.

Environment

• Claude Code 2.1.220
• macOS
• Plugins installed from a git-backed marketplace, auto-update enabled
• One user-level agent definition outside any plugin (this one always registered)