Skip to content

Support for workspace-specific plugin enablement #4

Description

@connor4312

Claude Code and Copilot allow users to configure which plugins are enabled for a repository, for example in .claude/settings.json:

{
  "enabledPlugins": {
    "code-formatter@company-tools": true,
    "deployment-tools@company-tools": false
  }
}

There are some considerations about this approach:

  1. It requires clients form the @company-tools marketplace name in a consistent way. This is obvious if the format for extraPluginMarketplaces is adopted as in Support for additional project-specific marketplaces #3 and github repos are canonically labelled as owner/repo, but for example VS Code supports loading plugin marketplaces from the filesystem and we could not form a portable short label from the marketplace definition alone.

    Perhaps this should use the marketplace name, but this is different behavior than what tools do today afaik

  2. The fact that this is an enablement map has always felt messy to me. In the above example, deployment-tools@company-tools is 'disabled', but why would a single repository know that I have that installed globally? And if I have that installed, why does the repository get to turn it off? That would take me a while to troubleshoot in my workflow if I didn't know why e.g. my hooks weren't running.

    I feel that a suggestedPlugins: string[] would be a bit of a nicer experience, and then whatever client/harness the user is driving can give them affordances to install+enable recommended plugins, or disable them as appropriate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions