[FEATURE] Support per-project enabledPlugins in .claude/settings.json

[AdrienneBosch]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Problem

enabledPlugins only works in the global ~/.claude/settings.json. There's no way to enable or disable a plugin per project. This means a plugin that's useful in one project loads its full skill descriptions into every project's context — even projects that set all the plugin's skills to "off" via skillOverrides.

The gap

Per-project overrides exist for most settings: permissions, hooks, skillOverrides, env. But enabledPlugins is global-only. This creates an asymmetry:

Setting	Global	Per-project
permissions	✅	✅
hooks	✅	✅
skillOverrides	✅	✅
env	✅	✅
enabledPlugins	✅	❌

Why skillOverrides: "off" doesn't solve this

Setting a plugin's skills to "off" suppresses auto-triggering but does not prevent the skill descriptions from loading into the system prompt. A project that disables all 28 anthropic-skills via skillOverrides still pays ~4,800 tokens per turn for descriptions it never uses.

Measured impact

From a real project audit (Opus 4, 200k context window):

• 28 plugin skills set to "off" in project settings.local.json
• All 28 descriptions still appear in the system prompt every turn
• Cost: ~4,800 tokens/turn (2.4% of context window)
• 6 of those skills duplicate project-level skills, adding ~920 tokens of pure redundancy

On a 200k window this is tolerable. On smaller models or projects that push the context limit, it's a meaningful loss — and it's entirely uncontrollable.

Proposed solution

Allow enabledPlugins in project-level .claude/settings.json (or .claude/settings.local.json), with the same merge semantics as other per-project settings. A project that sets "anthropic-skills": false at the project level would not load that plugin's skill descriptions into context for sessions in that project.

// .claude/settings.json (project-level)
{
  "enabledPlugins": {
    "anthropic-skills": false
  }
}

Proposed Solution

1. skillOverrides: "off" should mean off
   The simplest change and the one that fixes the most pain. If I set a skill to "off", its description should not load into context.
2. Per-project enabledPlugins for bulk control
   Individual skillOverrides entries work for fine-grained control. But when I want to disable an entire plugin for a project, I shouldn't have to list all 28 skills one by one. A project-level enabledPlugins: { "anthropic-skills": false } should disable the whole plugin for that project — no descriptions loaded, no skills available.

Alternative Solutions

The only current workaround is disabling the plugin globally in ~/.claude/settings.json, which affects all projects — including ones where the plugin is wanted.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

I use the anthropic-skills plugin globally — it's useful for general-purpose work. But I have one project with its own custom skills that cover the same ground. I don't need the plugin there.

Today:

I set all 28 plugin skills to "off" in my project's settings.local.json.
They still load into context every turn. ~4,800 tokens.
Autocompact can't evict them — they're in the system prompt.
My only option is disabling the plugin globally, which breaks my other projects.
With per-project enabledPlugins:

I add "anthropic-skills": false to my project's .claude/settings.json.
No descriptions load. 4,800 tokens freed.
The plugin still works in every other project.

Additional Context

No response

[github-actions]

Found 3 possible duplicate issues:

1. [FEATURE] Project-level plugin loading: let projects control which plugins (and their MCP tools) are active #46612
2. Feature: per-project plugin enable/disable override #40826
3. [FEATURE] Per-project plugin configuration and CLI initialization support #11461

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[AdrienneBosch]

This issue has not been resolved. All other issues have been closed without resolution or say that the issue has been fixed six months ago but has not.

[dx0ne]

It would be such a token saver. Like in some projects I don't need vercel plugin.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[Garcia6l20]

Claude it self could resolve it in ~3min, please plan it !