From the Inside Claude Code - The Claude Code Ecosystem architecture map
Partner MCP plugins launch unpinned packages on every user's machine
Several integration plugins start their server from a moving target: Playwright runs npx @playwright/mcp@latest, Firebase runs npx firebase-tools@latest, and Serena runs uvx from the default branch of github.com/oraios/serena. Only Terraform pins a version (Docker image 0.4.0). Whatever those registries or that branch serve next is what users execute, with the session's file and tool access.
Impact: A compromised upstream release or branch would run arbitrary code for every user of these plugins, unreviewed by this repo's CI.
Recommendation (small effort): Pin each launcher to an exact version (or a commit for uvx git sources) in its .mcp.json, and let the SHA-bump job move the pins so upgrades pass through scan and validation.
The trail
Open on the mapMore from this board
- Optional SessionStore methods raise instead of being absent, so a change in Types reaches 13 modules
- The Lowerer is one struct spread over 38 files and 29,700 lines with no unit tests
- Day 1: start with marketplace.json, the contract everything else serves
- Every SDK module imports its exceptions from one file, _errors.py
- PR-controlled agent config is restored from the base branch before Claude starts
- Control-protocol failures escape the SDK exception hierarchy
- The triage and dedupe agents are boxed in identity, tools and network
- Label decisions by the triage agent leave no reason a maintainer can see
- Spend and run length are bounded at the transport
- The subprocess transport carries five responsibilities in one file
- Every agent-driven closure has a human override before it happens
- Skip for now: config-only integrations, CI plumbing and single-file plugins
- External-PR workflows never execute contributor code