plugin.json
A Claude Code settings key, read out of the shipped bundle. No mined inventory carries it: everything below comes from what this site has written about it.
Skill listing and job tracking now go through the storage layer instead of touching files directly.
Not Anthropic's. This is the line from the earliest changelog entry here that named it, v2.1.223.
In the changelogs
30Releases whose published page names plugin.json.
-
v2.1.302
Plugin manifest conflicts are now collected as errors for each plugin
A clash between a plugin's plugin.json and its marketplace entry is now recorded as an error in a list instead of failing the load
found in this entry's text
-
v2.1.295
Plugin names are read from plugin.json, and marketplace clones get a path
Claude Code reads a plugin's name from its plugin.json file, and cloning a plugin marketplace now also passes a path
found in this entry's text
-
v2.1.287
Plugin names that imitate Anthropic's are now flagged when validated
Plugin checks now give an error for names that start with claude-, anthropic- or similar, and a warning for looser look-alikes
found in this entry's text
-
v2.1.281
Plugin directory detection recognises marketplace roots
A folder with .claude-plugin/marketplace.json but no plugin.json is now treated as a marketplace root
found in this entry's text
-
v2.1.281
Plugin validation now checks a plugin's MCP server files
Plugin validation now checks a plugin's MCP server files for bad settings, insecure addresses and credentials left in plain text
found in this entry's text
-
v2.1.271
New plugin type-contract validator and claude-code-plugins.d.ts generator
Plugin type contracts get strict validation and a generated claude-code-plugins.d.ts file
found in this entry's text
-
v2.1.271
Plugin manifests can declare a
typesfield for hooks-module engine interfacesPlugin manifests can now declare a
typesfield describing what they expose on the shared$interfacefound in this entry's text
-
v2.1.271
Plugin manifest gains a
typesfield declaring EngineInterface members on$Plugin manifests can now declare a
typesfield describing what they add to the$interfacefound in this entry's text
-
v2.1.268
Plugin manifest path-traversal checks consolidated into a shared helper
Plugin path-traversal checks unified into one shared helper function
found in this entry's text
-
v2.1.265
Plugin marketplace listings enriched from each plugin's own plugin.json
Plugin marketplace listings now fill in missing display info by reading the plugin's own plugin.json
named in this entry, found in this entry's text
-
v2.1.246
A bad plugin config no longer takes the plugin down
A plugin with bad config now loads on defaults instead of failing, when enabled from trusted settings.
found in this entry's text
-
v2.1.235
plugin evalgains --eval-dir and a manifest eval directory, still early accessplugin eval gets a configurable case directory via --eval-dir or a manifest key, still gated as early access
found in this entry's text
-
v2.1.233
/plugin validateworks on directories without a plugin manifestYou can point /plugin validate at any folder and it checks the skills, agents and commands inside.
found in this entry's text
-
v2.1.233
Plugin and marketplace validation warns about symlinks and checks each plugin.json fully
Marketplace validation warns about symlinks and fully validates every plugin.json, not just its version.
found in this entry's text
-
v2.1.223
Skills and jobs load through the storage sidecar
Skill listing and job tracking now go through the storage layer instead of touching files directly.
found in this entry's text
-
v2.1.223
Skills discovery skips disabled plugins
Skills belonging to plugins you disabled no longer show up in skill discovery.
found in this entry's text
-
v2.1.213
SDK Protocol: Plugin Version Field
found in this entry's text
-
v2.1.206
Plugin Binary Provisioning — Mismatch Detection and Bare Name Linking
found in this entry's text
-
v2.1.140
Plugin Path Descriptions Clarified — Override vs. Addition Semantics
found in this entry's text
-
v2.1.140
Plugin Folder-Shadowing Warnings
found in this entry's text
-
v2.1.118
/plugin tag Command
found in this entry's text
-
v2.1.118
Custom Theme Creation and Management
found in this entry's text
-
v2.1.110
Plugin Dependency Auto-Installation
found in this entry's text
-
v2.1.108
Plugin Version Resolution Tracking
found in this entry's text
-
v2.1.105
Plugin Monitors (Background Watch Scripts)
found in this entry's text
-
v2.1.105
Plugin Path Traversal Protection
found in this entry's text
-
v2.1.72
Plugin Source Resolution Improvements
found in this entry's text
-
v1.0.128
Plugin Marketplace System
found in this entry's text
-
v1.0.103
npm Plugin Support
found in this entry's text
-
v1.0.81
Plugin System (Experimental)
found in this entry's text
First cited
5The earliest release whose published evidence quoted plugin.json was v2.1.110, 15 Apr 2026. That is the oldest release this project wrote about it, so it is a floor on the name's age and not the release that introduced it. It is not a presence reading: which builds carried the name is the table below.
Presence across releases
0The miner has never read a build containing this name. It is here because a changelog entry of ours names it, which is evidence that it existed and not evidence of which releases carried it. The inventory starts at v2.1.138 and everything older than that was never mined.
Read out of the published npm bundle release by release, and out of Anthropic's own documentation as this site captured it. Nothing on this page is a description anybody here wrote about what the settings key does. All settings keys.