Feature: Separate declarative plugin config from runtime state for version control

Resolved 💬 4 comments Opened Jan 27, 2026 by felho Closed Feb 28, 2026

Problem

The current known_marketplaces.json file mixes declarative configuration with runtime state, making it unsuitable for version control:

{
  "claude-plugins-official": {
    "source": {
      "source": "github",
      "repo": "anthropics/claude-plugins-official"  // ← Declarative (should be tracked)
    },
    "installLocation": "/Users/felho/.claude/plugins/marketplaces/...",  // ← Machine-specific
    "lastUpdated": "2026-01-27T22:10:56.520Z"  // ← Runtime state
  }
}

Why This Matters

Plugins are an important part of how Claude Code behaves. Following the package.json / node_modules pattern:

| Tracked | Not Tracked |
|---------|-------------|
| package.json (declarative) | node_modules/ (generated) |
| package-lock.json (reproducible) | - |

Currently there's no clean way to:

  1. Version control which marketplaces/plugins a project uses
  2. Share plugin configuration across machines/team members
  3. Reproduce the same Claude Code setup on a different machine

Proposed Solution

Separate into two files:

marketplace-sources.json (declarative, version-controlled):

{
  "marketplaces": [
    { "source": "github", "repo": "anthropics/claude-plugins-official" }
  ]
}

marketplace-state.json (runtime, gitignored):

{
  "claude-plugins-official": {
    "installLocation": "/Users/...",
    "lastUpdated": "2026-01-27T22:10:56.520Z"
  }
}

This mirrors established patterns like:

  • package.json vs node_modules/
  • Terraform *.tf vs *.tfstate
  • Poetry pyproject.toml vs poetry.lock

Benefits

  1. Users can commit their plugin/marketplace configuration
  2. Teams can share standardized Claude Code setups
  3. Machine-specific paths and timestamps don't pollute git history
  4. claude plugin install could read from the declarative config file

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗