[FEATURE] Allow --plugin-dir to override managed plugins of the same name for local development

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

When a team mandates a plugin via managed-settings.json, there is no way for the plugin's developers to test a local development version in a live Claude session.

• --plugin-dir ./plugins/my-plugin/ loads the local plugin alongside the managed version rather than replacing it, causing duplicate hook execution.
• --bare skips plugin sync (which would solve the problem), but also disables OAuth/keychain auth — making it unusable for anyone on a team subscription without an explicit ANTHROPIC_API_KEY.
• --setting-sources controls user/project/local settings but does not affect managed settings, which sit at the highest precedence tier.

This creates a gap for plugin developers: offline testing (unit tests, piping JSON to hook binaries) covers core logic, but there's no way to verify plugin loading, hook wiring, and end-to-end behavior in a real session.

Proposed Solution

Any of the following would work:

1. --plugin-dir overrides managed plugins by name — if a local plugin has the same name as a managed plugin, the local version takes precedence for that session.
2. A --no-managed-plugins flag — opt out of managed plugin loading for a session while preserving all other settings and auth.
3. --bare --auth (per #38022) — if --bare could preserve OAuth/keychain auth, it would be usable as a workaround since it already skips plugin sync.

Option 1 is the most targeted and least disruptive to existing behavior.

Alternative Solutions

Offline testing (unit tests, direct binary invocation) covers most development needs but cannot verify plugin loading, hook registration, or the full plugin lifecycle in a live Claude session.

Priority

Medium - Would be very helpful

Feature Category

Plugins and extensions

Use Case Example

I maintain a Claude Code plugin that my team mandates via managed settings. During development, I need to test changes in a live session before publishing. Today I cannot do this without either (a) asking a team admin to temporarily un-mandate the plugin, or (b) using a separate personal account outside the team.

Additional Context

Related issues:

• #38022 — requests --bare with preserved OAuth (same auth problem, different use case: context isolation for reproducible scoring)
• #17773 — requests admin-level control to allow users to disable managed plugins (closed as stale; focuses on admin policy, not developer override)