## Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ## Problem Statement As of Claude Code [v2.1.195](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#21195), plugins in a checked-in `settings.json` file no longer auto-install when starting chat sessions in a given repo. This

[FEATURE] Treat Plugins as First-class Vendored Dependencies

Open 💬 0 comments Opened Jul 2, 2026 by dflor003

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

As of Claude Code v2.1.195, plugins in a checked-in settings.json file no longer auto-install when starting chat sessions in a given repo. This makes sense from a security perspective to mitigate supply chain attacks in AI plugins. However, many teams have been treating AI plugins the same way we'd treat a given repo's vendored packages from tools such as NPM, pip, and NuGet. With the 2.1.195 update, this breaks use-cases like the following.

Use the enabledPlugins in a checked-in settings.json to ensure certain 3rd party plugins/skills always get loaded for a given repo.
Org-wide plugins/skills marketplace with certain org-specific skills being automatically loaded for all users of a given repo.
CI-driven automated AI workflows that require certain skills to work.

Proposed Solution

AI plugins (and the skills, agents, MCPs, and hooks that they bundle) seem no different than any other vendored libraries through package managers. The proposal is to treat them as such and make them a 1st class artifact that gets checked into a given repository with the plugins it requires to function. There's several layers to this solution and I'd like to propose each one individually.

Layer 1: Trusted Marketplaces

Introduce a concept of "trusted marketplaces" that can be set up per-repo or rolled out via org-wide managed settings. In addition to that, add a setting to allow installing plugins from trusted marketplaces automatically. Trusted marketplaces could include things like:

Anthropic's own claude-plugins-official marketplace
Marketplaces that the org built themselves for cross-org plugins
Plugins from known, trusted vendors like Microsoft, Google, etc.

Ideally, for these trusted marketplaces, the behavior could be almost identical to the way it was pre-2.1.195. The enhancement to settings.json could look something like one of the following:

{
  "autoInstallTrustedPlugins": true, // If explicit opt-in is preferred
  "extraKnownMarketplaces": {
    "dotnet-agent-skills": {
      "source": {
        "source": "github",
        "repo": "dotnet/skills",
        "trusted": true // Alternatively "autoLoad" or "autoInstall". Should default to false.
      }
    }
  }
}

{
  "autoInstallTrustedPlugins": true, // If explicit opt-in is preferred
  "trustedMarketplaces": ["dotnet-agent-skills"], // If you don't want to change the known marketplaces schema
  "extraKnownMarketplaces": {
    "dotnet-agent-skills": {
      "source": {
        "source": "github",
        "repo": "dotnet/skills"
      }
    }
  }
}

Layer 1 Alternative: Trusted Plugins

The layer 1 proposal trusts _entire marketplaces_. If this isn't desired, you could also trust at the individual plugin level. The concept would largely be the same with the only thing differing is the scope of what is trusted. Either level of scope solves the underlying problem. The key here is allowing a user to acknowledge that they trust a certain set of resources (whether that's plugins or marketplaces).

Layer 2: Claude CLI Install All Support

Note: If layer 1 is not desired, then just layers 2 & 3 together would be enough to solve the problem.

There have been several proposals in the past to add a way to install all plugins in a given repo:

All of these, so far haven't picked up any kind of traction. I'd like to revisit those decisions with the framing that plugins & skills are vendored packages and in the context of the other proposed changes in this issue. A dev working in a repo has a reasonable expectation that they'd need to run some package manager's install command to get the repo's dependencies. It's also reasonable that a dev should have to do the same to get a repo's AI plugin dependencies. For example, this could look something like the following to the end-user:

# Simplest version
$ claude plugin install 

# More explicit
$ claude plugin install --all # As proposed in issue 26561

# If you want to explicitly write the scope
$ claude plugin install --scope project

The key here is that this should be runnable by both users and CI workflows to fetch the desired plugins and (see Layer 3) ensure that they are pinned to a known working version.

Layer 3: Lockfiles & Explicit Updates

To guard against potential supply chain attacks, you can introduce a concept similar to a packages-lock.json in NPM. When a plugin is installed at the project scope, this should pin the version of the plugin either via its git commit hash or plugin version number from the marketplace. This would guard against a malicious update in the plugin repo from automatically getting loaded into many downstream repos or automated CI workflows without explicit user consent.

This could be done either directly in settings.json or in a new plugins.json in the .claude folder where plugins could live longer term and the lock files could be names something like settings-lock.json or plugins-lock.json.

Since versions are pinned, this also creates the need for some CLI support to be able to update to a newer version of a package. The CLI already supports this:

$ claude plugin update <plugin-name>@<marketplace>

The enhancement here would be to also bump the lockfile whenever a claude plugin update command is run.

Alternative Solutions

Prior to 2.1.195, we could achieve this easily by just setting the plugins we want for a given repo in the settings.json via a combination of enabledPlugins and extraKnownMarketplaces. After 2.1.195, this whole vendored approach is effectively gone. There's several workarounds, but each one has its own issues:

Workaround: Install all plugins across all repos globally

When a dev is onboarded, they either run a script or manually install all the plugins they'll ever need to their user-level settings.

Why this isn't ideal:

Works OK for small number of repos and devs, but does not scale to a large enterprise with 100s of devs and repos.
Plugins required for repos will change over time. If a repo has a new required plugin, that means all devs now need to install it to be in compliance.
Does not address autonomous CI workflows.
You end up paying the context cost of ALL skills, agents, MCPs, and hooks from all plugins on every AI chat session even when most of them are not necessary for the work you are doing.

Workaround: Repo-level install script

Add a simple install script to every repo to install its required plugins. The first time a dev loads the repo, they run the install script to get all the plugins installed into the project scope.

Why this isn't ideal:

Additional maintenance for each repo in the form of this script.
If Claude Code ever changes the format of plugins in settings.json this script could potentially break across many repos.
Effectively bypasses the security benefits of not automatically installing all plugins in settings.json automatically.

Workaround: Global CLI install tool

Create a CLI tool to automatically install all plugins in settings.json. Devs install the tool once on their machine and run something roughly equivalent to npm install in every repo to setup the repo's plugins.

Why this isn't ideal:

Additional maintenance for each repo in the form of this CLI tool.
If Claude Code ever changes the format of plugins in settings.json this script could potentially break.
Effectively bypasses the security benefits of not automatically installing all plugins in settings.json automatically.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

Use Case 1: Internal Org-Wide Marketplace

We have an internal plugins marketplace that exposes some feature planning, story writing, and general business analysis skills. Individual teams reference these skills in their own team-specific planning repositories. We'd like all the downstream repos to automatically load these trusted internal skills across all users of the repos (both technical and non-technical).

Use Case 2: Trusted Vendors & CI Workflow

We create a support agent harness for our production applications that bundles our application context along with some internal skills and one or more 3rd party plugins provided by a cloud vendor (e.g. AWS, GCP, Azure) that enable the agent to operate both autonomously and via chats to troubleshoot and remediate production issues. We trust the skills coming directly from the Cloud vendor and would like them to automatically be loaded both for interactive chat sessions as well as in autonomous CI workflows to ensure the agents use the right skills and plugins and provide meaningful outputs.

Additional Context

_No response_

View original on GitHub ↗