[FEATURE] Machine-wide plugin scope: plugins are per CLAUDE_CONFIG_DIR while settings.json/enabledPlugins, CLAUDE.md and MCP can already be shared across profiles

Summary

Plugin installs are scoped to a single CLAUDE_CONFIG_DIR. There is no user-wide (machine-wide) scope that spans multiple config dirs, even though the other pieces of the setup already can be shared. Please add a machine-level plugin scope (or honor a managed plugin store), the same way MCP servers can be declared once in managed-mcp.json for every profile.

Setup

Windows 11, Claude Code 2.1.263. Eight profiles (one CLAUDE_CONFIG_DIR each: ~/.claude, ~/.claude-accounts/claude1, ... claudemax, design) used to run parallel sessions on separate Max accounts.

What can already be shared across those profiles today:

| Piece | How it is shared |
|---|---|
| settings.json (incl. enabledPlugins, extraKnownMarketplaces, hooks) | one file, every profile's copy is a symlink |
| CLAUDE.md | symlink |
| MCP servers | C:\Program Files\ClaudeCode\managed-mcp.json, applies to all profiles |
| memory | projects/<slug>/memory junctioned to one directory |

What cannot: the plugin store. plugin install writes installed_plugins.json, known_marketplaces.json, and cache/ under the active CLAUDE_CONFIG_DIR/plugins/ only. --scope accepts user | project | local, and user means "this config dir".

Why this is a problem

1. Enabled-but-not-installed drift. enabledPlugins lives in the shared settings.json, so a plugin installed in profile A is enabled in profiles B..H but has no payload there. Each profile has to be installed into separately, by hand, with the same two commands, and kept at the same version.
2. The only workaround is a junction/symlink of the whole plugins/ dir into every profile. That works, but it is exactly the setup that trips the installLocation validation reported in #82272 and #85325 (literal-path compare, not realpath), so users who do the sensible thing get "corrupted" warnings.
3. Plugins with SessionStart/UserPromptSubmit hooks are meant to be always-on (caveman, ponytail, context-mode). "Always-on in one of eight profiles" is not what anyone installing them intends.

Requested behavior

Either of these would close the gap:

• A new install scope, e.g. --scope machine (or global), that writes the store to a fixed shared location (%LOCALAPPDATA%\ClaudeCode\plugins / ~/.local/share/claude/plugins, or a path set by CLAUDE_PLUGINS_DIR) and is consulted by every CLAUDE_CONFIG_DIR. Marketplaces added at that scope are likewise visible everywhere.
• Or: a managed plugin store next to managed-settings.json / managed-mcp.json, so an admin can declare "these marketplaces + these plugins" once for the machine.

In both cases, the resolution order should be project > local > user (config dir) > machine, and plugin list should show which scope each plugin came from. Realpath-based validation (#82272) would also make the existing symlink workaround stop warning, but a first-class scope is the real fix.

Steps to reproduce (current behavior)

set CLAUDE_CONFIG_DIR=C:\Users\me\.claude-accounts\a
claude plugin marketplace add DietrichGebert/ponytail
claude plugin install ponytail@ponytail        # installs into ...\a\plugins

set CLAUDE_CONFIG_DIR=C:\Users\me\.claude-accounts\b   # settings.json is a symlink to the same file
claude plugin list                             # ponytail enabled in settings, not installed here

Expected: a way to make that single install apply to profile b too without repeating the install or junctioning the directory.

Related

#74393 (/plugin install ignoring CLAUDE_CONFIG_DIR), #82272 / #85325 (symlinked shared plugin store flagged as corrupted), #55594 (absolute install paths).