[FEATURE] Per-project plugin configuration and CLI initialization support
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
Currently, Claude Code's plugin system applies globally - plugins enabled in one project remain enabled in all projects. This creates significant workflow friction when working across multiple projects with different requirements:
No project-scoped plugin control: While the documentation mentions repository-level configuration via .claude/settings.json, there is no way to have plugins automatically enable/disable based on the current project directory No CLI initialization: Unlike other modern dev tools (e.g., npm init, git init), there's no command to initialize project-specific Claude Code configuration Manual workarounds required: Developers must manually toggle plugins with /plugin enable/disable when switching projects, or maintain their own scripts
Proposed Solution
Add native support for project-scoped plugin management:
Automatic plugin activation: When working in a directory with .claude/settings.json, automatically enable/disable plugins specified in that file CLI initialization command: Add a command like claude init or claude config init to scaffold basic project configuration:
bash claude init
- Creates .claude/settings.json with interactive prompts
- Optionally initializes CLAUDE.md template
Clear precedence model: Project settings override global settings for plugins, similar to how .gitconfig works
Alternative Solutions
Manual enable/disable: Current workaround, but error-prone and tedious Shell scripts/aliases: Possible but not portable or standardized Global-only configuration: Doesn't support multi-project workflows
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
This would benefit:
Developers working on multiple projects with different tooling needs (e.g., Python projects needing different plugins than JavaScript projects) Teams sharing configurations - ensure consistent plugin usage per-project in version control Consultant/contractor developers switching between client projects frequently Open source maintainers who work across many repositories
Additional Context
No response
This feature already exists. You just need to add a block like this inside your project's .claude/settings.json:
{
"enabledPlugins": {
"feature-dev@claude-code-plugins": true,
"superpowers-developing-for-claude-code@superpowers-marketplace": true,
"superpowers@superpowers-marketplace": false,
"example-skills@anthropic-agent-skills": false
}
}
However, I agree that the /plugin TUI in Claude Code is confusing, because it's not clear whether it's modifying .claude/settings.json or ~/.claude/settings.json. To avoid the ambiguity, it's better to just edit the JSON files directly.
Thank you - Is this in the documentation somewhere? Why would there not be a CLI interface to do this? This is far too clunky and unnecessary. It should be an option in the CLI to enable for global vs project. Users should not be writing json themselves, regardless if most of the users are capable of doing so.
On Wed, Nov 12, 2025 at 11:55 PM Nikhil Maddirala @.***> wrote:
nikhilmaddirala left a comment (anthropics/claude-code#11461) https://github.com/anthropics/claude-code/issues/11461#issuecomment-3525369146
This feature already exists. You just need to add a block like this inside your project's .claude/settings.json:
{ "enabledPlugins": { @.": true, @.": true, @.": false, @.": false } }
— Reply to this email directly, view it on GitHub https://github.com/anthropics/claude-code/issues/11461#issuecomment-3525369146, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE6JBCA2C4Z4F3HIKBTRZCT34QFK7AVCNFSM6AAAAACL26D7YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRVGM3DSMJUGY . You are receiving this because you authored the thread.Message ID: @.***>
This feature already exists. You just need to add a block like this inside your project's
.claude/settings.json:{ "enabledPlugins": { "feature-dev@claude-code-plugins": true, "superpowers-developing-for-claude-code@superpowers-marketplace": true, "superpowers@superpowers-marketplace": false, "example-skills@anthropic-agent-skills": false } } However, I agree that the
/pluginTUI in Claude Code is confusing, because it's not clear whether it's modifying.claude/settings.jsonor~/.claude/settings.json. To avoid the ambiguity, it's better to just edit the JSON files directly.
As of today, the issue with this approach is, as soon as we comment out with // any of the enabled plugin (equivalent to disabling it) , all of the plugins disappear. I guess it is because claude code considers the comments in the json as invalid.
For example, I have this in my ~/.claude/settings.json :
{
"enabledPlugins": {
"pr-review-toolkit@claude-code-plugins": true,
"feature-dev@claude-code-plugins": true,
"security-guidance@claude-code-plugins": true,
"code-review@claude-code-plugins": true,
"frontend-design@claude-code-plugins": true,
"code-documentation@claude-code-workflows": true,
"debugging-toolkit@claude-code-workflows": true,
"git-pr-workflows@claude-code-workflows": true,
"backend-development@claude-code-workflows": true,
"frontend-mobile-development@claude-code-workflows": true,
"full-stack-orchestration@claude-code-workflows": true,
"unit-testing@claude-code-workflows": true,
"tdd-workflows@claude-code-workflows": true,
"code-review-ai@claude-code-workflows": true,
"code-refactoring@claude-code-workflows": true,
"dependency-management@claude-code-workflows": true,
"error-debugging@claude-code-workflows": true,
"team-collaboration@claude-code-workflows": true,
"llm-application-dev@claude-code-workflows": true,
"agent-orchestration@claude-code-workflows": true,
"context-management@claude-code-workflows": true,
"incident-response@claude-code-workflows": true,
"error-diagnostics@claude-code-workflows": true,
"observability-monitoring@claude-code-workflows": true,
"deployment-strategies@claude-code-workflows": true,
"deployment-validation@claude-code-workflows": true,
"kubernetes-operations@claude-code-workflows": true,
"cloud-infrastructure@claude-code-workflows": true,
"cicd-automation@claude-code-workflows": true,
"application-performance@claude-code-workflows": true,
"database-cloud-optimization@claude-code-workflows": true,
"comprehensive-review@claude-code-workflows": true,
"performance-testing-review@claude-code-workflows": true,
"framework-migration@claude-code-workflows": true,
"codebase-cleanup@claude-code-workflows": true,
"database-design@claude-code-workflows": true,
"database-migrations@claude-code-workflows": true,
"security-scanning@claude-code-workflows": true,
"security-compliance@claude-code-workflows": true,
"backend-api-security@claude-code-workflows": true,
"frontend-mobile-security@claude-code-workflows": true,
"data-validation-suite@claude-code-workflows": true,
"api-scaffolding@claude-code-workflows": true,
"api-testing-observability@claude-code-workflows": true,
"seo-content-creation@claude-code-workflows": true,
"seo-technical-optimization@claude-code-workflows": true,
"seo-analysis-monitoring@claude-code-workflows": true,
"documentation-generation@claude-code-workflows": true,
"multi-platform-apps@claude-code-workflows": true,
"business-analytics@claude-code-workflows": true,
"hr-legal-compliance@claude-code-workflows": true,
"customer-sales-automation@claude-code-workflows": true,
"content-marketing@claude-code-workflows": true,
"payment-processing@claude-code-workflows": true,
"accessibility-compliance@claude-code-workflows": true,
"python-development@claude-code-workflows": true,
"javascript-typescript@claude-code-workflows": true,
"systems-programming@claude-code-workflows": true,
"jvm-languages@claude-code-workflows": true,
"shell-scripting@claude-code-workflows": true,
"developer-essentials@claude-code-workflows": true
},
"alwaysThinkingEnabled": false,
"feedbackSurveyState": {
"lastShownTime": 1754001417825
}
}
commenting out 3 tools make the JSON and claude code won't recognize any of the plugins:
{
"enabledPlugins": {
"pr-review-toolkit@claude-code-plugins": true,
"feature-dev@claude-code-plugins": true,
"security-guidance@claude-code-plugins": true,
"code-review@claude-code-plugins": true,
"frontend-design@claude-code-plugins": true,
"code-documentation@claude-code-workflows": true,
"debugging-toolkit@claude-code-workflows": true,
"git-pr-workflows@claude-code-workflows": true,
"backend-development@claude-code-workflows": true,
"frontend-mobile-development@claude-code-workflows": true,
"full-stack-orchestration@claude-code-workflows": true,
"unit-testing@claude-code-workflows": true,
"tdd-workflows@claude-code-workflows": true,
"code-review-ai@claude-code-workflows": true,
"code-refactoring@claude-code-workflows": true,
"dependency-management@claude-code-workflows": true,
"error-debugging@claude-code-workflows": true,
"team-collaboration@claude-code-workflows": true,
"llm-application-dev@claude-code-workflows": true,
"agent-orchestration@claude-code-workflows": true,
"context-management@claude-code-workflows": true,
"incident-response@claude-code-workflows": true,
"error-diagnostics@claude-code-workflows": true,
"observability-monitoring@claude-code-workflows": true,
"deployment-strategies@claude-code-workflows": true,
"deployment-validation@claude-code-workflows": true,
"kubernetes-operations@claude-code-workflows": true,
"cloud-infrastructure@claude-code-workflows": true,
"cicd-automation@claude-code-workflows": true,
"application-performance@claude-code-workflows": true,
"database-cloud-optimization@claude-code-workflows": true,
"comprehensive-review@claude-code-workflows": true,
"performance-testing-review@claude-code-workflows": true,
"framework-migration@claude-code-workflows": true,
"codebase-cleanup@claude-code-workflows": true,
"database-design@claude-code-workflows": true,
"database-migrations@claude-code-workflows": true,
"security-scanning@claude-code-workflows": true,
"security-compliance@claude-code-workflows": true,
"backend-api-security@claude-code-workflows": true,
"frontend-mobile-security@claude-code-workflows": true,
"data-validation-suite@claude-code-workflows": true,
"api-scaffolding@claude-code-workflows": true,
"api-testing-observability@claude-code-workflows": true,
// "seo-content-creation@claude-code-workflows": true,
// "seo-technical-optimization@claude-code-workflows": true,
// "seo-analysis-monitoring@claude-code-workflows": true,
"documentation-generation@claude-code-workflows": true,
"multi-platform-apps@claude-code-workflows": true,
"business-analytics@claude-code-workflows": true,
"hr-legal-compliance@claude-code-workflows": true,
"customer-sales-automation@claude-code-workflows": true,
"content-marketing@claude-code-workflows": true,
"payment-processing@claude-code-workflows": true,
"accessibility-compliance@claude-code-workflows": true,
"python-development@claude-code-workflows": true,
"javascript-typescript@claude-code-workflows": true,
"systems-programming@claude-code-workflows": true,
"jvm-languages@claude-code-workflows": true,
"shell-scripting@claude-code-workflows": true,
"developer-essentials@claude-code-workflows": true
},
"alwaysThinkingEnabled": false,
"feedbackSurveyState": {
"lastShownTime": 1754001417825
}
}
As of today, the issue with this approach is, as soon as we comment out with
//any of the enabled plugin (equivalent to disabling it) , all of the plugins disappear. I guess it is because claude code considers the comments in the json as invalid.
@kunalshah JSON does not support comments, so what you're attempting is invalid syntax. You should just use the true/false values to enable/disable plugins.
Yes the way this works now is just unnecessarily clunky, and ends up sort of making it hard to realize the full benefit of plugins easily. The project level config doesn't exist at all, in the slash commands/cli subcommands, but as discussed, it's not really clear from the docs that its only global to begin with, had to sort of figure that out. I've ended up installing all the ones I use globally, with almost all disabled. Then I wrote a custom slash command to help do per project enablement, based on the project type, etc. Another issue/omission is no --plugins (like --agents) flag for the cli, which would also be great for starting up a session, or running 'sub claudes' with the only desired plugins.
Yes the way this works now is just unnecessarily clunky, and ends up sort of making it hard to realize the full benefit of plugins easily. The project level config doesn't exist at all, in the slash commands/cli subcommands, but as discussed, it's not really clear from the docs that its only global to begin with, had to sort of figure that out. I've ended up installing all the ones I use globally, with almost all disabled. Then I wrote a custom slash command to help do per project enablement, based on the project type, etc. Another issue/omission is no --plugins (like --agents) flag for the cli, which would also be great for starting up a session, or running 'sub claudes' with the only desired plugins.
agreed. and in light of Anthropic's recent article where the acknowledge the fundamental issue with MCP flooding context and making models worse, this seems like the same problem, and this feature or equivalent would be low-hanging fruit for solving this problem. I have made very cool plugins using claude, but they really should only be enabled in specific projects. I don't understand the point of having them only turned on globally. Everything about this defies the core principles of what Claude was built on.
Claude code is amazing and they are rapidly releasing amazing features, but this is VERY low hanging fruit to make the tool much more useful. And I don't think this just applies to plugins. There should really be a built-in claude SKILL for managing the configuration. (They should take a page out of Roo Code's book).
Thanks for creating this issue and digging into the problem. I’ve also been wanting this feature for a while, so I was really glad to find this discussion.
I often need to use different plugins for different repositories, and sometimes even for different sub-directories within the same repo. In those cases, it would be ideal if changes made through the CLI updated the project-level configuration instead of only touching the global settings. That would make the workflow much smoother and avoid unnecessary manual editing.
Having proper per-project plugin management feels essential for multi-repo work, and aligning the CLI behavior with that would be a huge quality-of-life improvement.
A related issue is that the current implementation does not correctly handle cases where the same Marketplace is installed from a GitHub source at the user level, while simultaneously being installed from a Directory source at the project level.
User Level Config (~/.claude/settings.json)
{
"extraKnownMarketplaces": {
"kokuyouwind-plugins": {
"source": {
"source": "github",
"repo": "kokuyouwind/claude-plugins"
}
}
},
"enabledPlugins": {
"dev-guidelines@kokuyouwind-plugins": true
}
}
Project Level Config (kokuyouwind-plugins/.claude/settings.json)
{
"extraKnownMarketplaces": {
"claude-code-plugins": {
"kokuyouwind-plugins-local": {
"source": {
"source": "directory",
"path": "./"
}
}
},
"enabledPlugins": {
"dev-guidelines@kokuyouwind-plugins-local": true
}
}
When Claude Code is launched with the above configuration and the Plugin Status is checked, a Marketplace conflict error occurs as shown below:
Marketplaces:
✘ kokuyouwind-plugins-local · Failed
Marketplace 'kokuyouwind-plugins' is already installed. Please remove it first using '/plugin marketplace remove kokuyouwind-plugins' if you want to re-install it.
In such conflicting cases, prioritizing the project-level configuration would allow users to utilize stable versions of plugins at the user level while easily verifying modified versions during project development.
I noticed that MCP server installation already has a --scope flag with local, project, and user options:
claude mcp add server-name --scope project
It would be great to have parity for plugins:
/plugin install plugin-name@marketplace --scope project
Currently /plugin install defaults to global (~/.claude/settings.json) with no way to specify scope via the CLI. The manual workaround of editing .claude/settings.json works, but having a flag would streamline the workflow - especially when onboarding team members or setting up new projects.
Looks like it was fixed in today's update! Thanks
Thanks @claude - I'll close this
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.