Project-scoped install silently suppresses the plugin in every other repo (upstream?)

[ecv]

What needs to happen

A plugin installed at project scope in one repo should not silently disable itself in every other repo. Today it does, and there is no signal.

Filing here to hold the repro; this looks like Claude Code behaviour rather than anything this marketplace controls, so it likely wants reporting upstream.

Reproduction

Claude Code on macOS, marketplace datum-cloud/claude-code-plugins:

1. Install a plugin at project scope from repo A. ~/.claude/plugins/installed_plugins.json records {"scope": "project", "projectPath": "<A>"}.
2. In repo B, declare the marketplace and "enabledPlugins": {"<plugin>@<marketplace>": true} in .claude/settings.json.
3. Open a session in repo B.

Expected: the plugin installs for B and its skills load.
Actual: no install. The skills are absent from the session, while claude plugin list still reports the plugin enabled.

Control: with no prior install record anywhere, step 2 alone auto-installs on the first session — silently, no trust prompt — recorded as project scope bound to B. The mechanism works. An existing binding to a different project is what suppresses it.

Workaround: claude plugin install <plugin> --scope user. User scope binds to no project. Verified to restore skill loading with the stale project entry left in place.

Why this matters

The failure mode is silence. A repo's CLAUDE.md can require a skill, settings can enable it, claude plugin list can confirm it — and the session still has no such skill and says nothing. In datum-cloud/infra that ran for weeks: sessions read an instruction to follow datum-platform:pr-conventions, found nothing, and produced GitHub content against a reconstructed guess at the conventions.

It also inverts who gets hurt. Anyone who never installed by hand is fine; the people broken are the earliest adopters, who have the oldest project-scoped record.

Second, related finding

claude plugin uninstall --scope project edits the project's .claude/settings.json to strip the plugin from enabledPlugins. In these repos that file is git-tracked, so a local uninstall silently stages a change that would remove the declaration for every teammate. Arguably a separate bug — a local operation shouldn't mutate tracked repo config as a side effect.

Desired outcome

Either a project-scoped record stops suppressing installs for other projects, or the mismatch is surfaced — anything louder than a skill that quietly isn't there.

• Report upstream to Claude Code
• Decide whether a CLAUDE.md-required skill that isn't loaded can be detected locally

Related to #24, fixed for us by #25.