--plugin-dir does not override installed plugin with same name

Summary

--plugin-dir does not override an installed plugin with the same name. Even
after disabling the installed plugin with /plugin disable, --plugin-dir
still appears to load the cached version rather than the specified directory.

This makes it impossible to test local plugin changes during development
when the plugin is also installed from a marketplace.

Reproduction

1. Install a plugin from a marketplace:

``
claude plugin install my-plugin@my-marketplace
``

1. Make edits to the plugin source in a local working tree (e.g. change

an abort message in a skill)

1. Disable the installed plugin:

``
claude plugin disable my-plugin@my-marketplace --scope user
``

1. Launch Claude Code with the local directory:

``
claude --plugin-dir ./my-plugin-source
``

1. Invoke a skill and observe the output
2. Result: The old (cached) behavior is observed, not the edited version

Expected Behavior

Per the docs:

Use the --plugin-dir flag to test plugins during development. This loads your plugin directly without requiring installation.

And:

Plugins are specified in one of two ways: - Through claude --plugin-dir, for the duration of a session. - Through a marketplace, installed for future sessions.

--plugin-dir should load the plugin directly from the specified directory,
bypassing the cache entirely. If an installed plugin has the same name, the
--plugin-dir version should take precedence (or the installed version
should not load at all when --plugin-dir is specified).

Impact

This completely blocks the plugin development workflow. There is no way to
test local changes to a plugin that is also installed from a marketplace.
The documented development/testing flow (--plugin-dir for iteration, then
publish when ready) does not work.

Environment

• Claude Code CLI v2.1.71
• macOS