Claude Code Plugins prüfen, bevor du den offiziellen Marketplace installierst

Anthropic’s offizieller Claude Code Plugin-Marketplace ist kein Gerücht mehr, das irgendwo in Config-Ordnern vergraben liegt. Das öffentliche GitHub-Repo anthropics/claude-plugins-official hat Stand 17. Juni 2026 mehr als 30.000 Stars, und sein README beschreibt ein kuratiertes Verzeichnis mit internen Anthropic Plugins plus Einträgen von Drittanbietern. Im selben README steht auch der Satz, der deine Haltung bestimmen sollte: „Make sure you trust a plugin before installing, updating, or using it“, weil Anthropic nicht jeden MCP Server, jede Datei oder jede andere gebündelte Abhängigkeit in diesen Plugins kontrolliert (GitHub).

Diese Warnung ist kein juristischer Pflichttext. Ein Claude Code Plugin kann Slash-Commands, Skills, Agents, Hooks, MCP Server, LSP-Server, Executables und Settings bündeln. In normaler Entwickler-Sprache: Es kann Prompt-Kontext hinzufügen, lokale Prozesse starten, Remote-Services aufrufen, Shell-Hooks bei Lifecycle-Events ausführen und dem Modell neue Tools verfügbar machen.

Das richtige mentale Modell ist nicht: „Ich installiere ein Editor-Theme.“ Es ist: „Ich füge eine Abhängigkeit hinzu, die Code in der Nähe meines Source-Trees ausführen kann.“

Flussskizze eines Claude Code Plugin-Installationspfads vom Marketplace-Katalog über den lokalen Cache bis zu aktivierten Komponenten, mit fou

Anthropic hat Claude Code Plugins am 9. Oktober 2025 angekündigt und sie als Sammlungen von Slash-Commands, Agents, MCP Servern und Hooks beschrieben, die sich mit /plugin installieren lassen (Claude blog). Die aktuellen Claude Code Docs sagen, dass der offizielle Anthropic Marketplace claude-plugins-official automatisch verfügbar ist, wenn Claude Code startet, und dass du ein Plugin so installieren kannst:

/plugin install github@claude-plugins-official

Falls das Plugin fehlt, sagen die Docs, du sollst den Marketplace so aktualisieren:

/plugin marketplace update claude-plugins-official

oder ihn so hinzufügen:

/plugin marketplace add anthropics/claude-plugins-official

Das ist der offizielle Wohlfühlpfad (Claude Code docs). Er ist nützlich. Als operative Policy ist er aber unvollständig.

Die Marketplace-Datei im offiziellen Repo verweist auf eine Mischung aus lokalen Plugin-Verzeichnissen und externen Quellen, die per Commit-SHA gepinnt sind. Einträge können zum Beispiel GitHub-Repositories, Unterverzeichnisse, Refs und SHAs in .claude-plugin/marketplace.json referenzieren (raw marketplace file). Pinning hilft, ersetzt aber nicht die Prüfung dessen, was der gepinnte Code tatsächlich tut. Ein Plugin kann immer noch einen Server starten, nach Zugangsdaten fragen, Hooks ausführen oder von einem Binary abhängen, dessen Verhalten sich außerhalb des Marketplace-Manifests ändert.

Die Community sieht dasselbe. In einem aktuellen r/ClaudeAI-Thread zu wichtigen Claude Code Plugins empfahl eine Antwort zuerst CLAUDE.md und Hooks, danach nur projektspezifische MCP Server. Eine andere warnte davor, Claude Code mit „random connectors“ zu bewerfen, weil sie Tokens kosten und Kontext verschmutzen können (Reddit). Das ist jetzt die praktische Debatte: Plugins sind mächtig, aber jede zusätzliche Fähigkeit hat eine Kostenfläche.

Fang mit dem Manifest an, dann lies das Repo

Dein erstes Audit-Ziel ist die Plugin-Quelle. Installiere nichts aus Such-Snippets, kopierten Blog-Commands oder zufälligen Marketplace-Aggregatoren, bis du die Quelle zu einem Repo und Manifest zurückverfolgen kannst.

Im offiziellen Marketplace-Repo prüfst du:

Den Marketplace-Eintrag in .claude-plugin/marketplace.json
Den source-Typ, die URL, den Pfad, Ref und SHA
Die .claude-plugin/plugin.json des Plugins, falls vorhanden
Jede .mcp.json, .lsp.json, hooks/hooks.json, commands/, skills/, agents/, bin/ und Scripts

Anthropic’s Plugin-Referenz listet die zentralen Komponentenpfade auf. Hooks liegen in hooks/hooks.json, MCP Server können in .mcp.json liegen, Executables können in bin/ liegen, und Plugin-Manifeste können auf eigene Komponentenorte zeigen (Claude Code plugin reference). Das heißt: „Ich habe plugin.json geprüft“ reicht nicht. Ein Plugin kann sich auf Standard-Discovery-Pfade verlassen.

Ein schneller manueller Review sieht so aus:

git clone https://github.com/OWNER/PLUGIN-REPO /tmp/plugin-audit
cd /tmp/plugin-audit

find . -maxdepth 3 \( \
  -name plugin.json -o \
  -name hooks.json -o \
  -name .mcp.json -o \
  -name .lsp.json -o \
  -path "*/bin/*" -o \
  -path "*/scripts/*" \
\) -print

rg -n "curl|wget|bash|sh -c|chmod|open |xdg-open|osascript|token|api_key|secret|eval|exec|spawn|subprocess"

Dieser rg-Command ist grob, aber grob ist hier gut. Du suchst nach Überraschungen zur Installationszeit, Shell-Ausführung, Browser-Starts, Remote-Downloads, Umgang mit Zugangsdaten und Scripts, die dein Repo oder Home-Verzeichnis verändern.

Meine Regel: Wenn ein Plugin ein Shell-Script braucht, um seine Kernaufgabe zu erledigen, will ich vor der Installation jeden Command in diesem Script verstehen. Wenn es zur Laufzeit ein weiteres Artefakt herunterlädt, behandle ich dieses Laufzeit-Artefakt als Teil des Plugins.

MCP Server sind die teuerste „Bequemlichkeit“

MCP ist der Punkt, an dem Plugin-Komfort zu versteckten Kosten werden kann. Anthropic’s MCP Docs sagen, dass von Plugins definierte MCP Server automatisch starten, wenn das Plugin aktiviert wird, und dass Plugin-MCP-Tools neben manuell konfigurierten MCP-Tools erscheinen (Claude Code MCP docs). Die Docs sagen außerdem, dass Plugin-MCP-Server dieselben Environment-Variablen nutzen wie manuell konfigurierte Server. Das ist relevant, wenn deine Shell Cloud-Tokens, Datenbank-URLs oder interne Service-Credentials exportiert.

Die Beschwerde aus der Community ist konkret: MCP-Tool-Schemas können Kontext verbrauchen, bevor du überhaupt ein Tool aufrufst. In einem r/ClaudeCode-Thread zu Token-Overhead verwiesen Nutzer auf deaktivierte Plugins und das Fehlen schwergewichtiger MCP Server als wahrscheinlichen Grund für geringeren Token-Verbrauch, und ein Kommentator nannte MCP-Tool-Schemas „a huge hidden cost“ (Reddit). In einem anderen Thread behauptete ein Kommentator, verbundene MCP Server registrierten Tool-Schemas im Kontext, und empfahl, Server pro Session auszudünnen (Reddit).

Behandle genaue Token-Schätzungen von Reddit als anekdotisch, solange du sie nicht in deinem eigenen Setup reproduzierst. Die Richtung dahinter stimmt trotzdem: Ein immer aktiver Server mit vielen ausführlichen Tools ist nicht kostenlos.

Nutze diese Entscheidungstabelle, bevor du ein Connector-artiges Plugin installierst:

Bedarf	Sichererer Standard	MCP nutzen, wenn
GitHub-Operationen ausführen	`gh` CLI über Bash	Claude Issues, PRs und Metadaten interaktiv durchsuchen muss
Eine Datenbank abfragen	Read-only CLI oder lokales Script	Claude strukturierte Tool-Calls mit begrenzten Credentials braucht
Cloud-Ressourcen inspizieren	Vendor-CLI mit expliziten Commands	Der MCP Server enge Berechtigungen und klare Audit-Logs hat
Docs abrufen	Statische Docs, Repo-Dateien oder Weblinks	Ressourcen groß, dynamisch und häufig referenziert sind
Policy erzwingen	`PreToolUse` Hook	Die Entscheidung Claude-sichtbaren Kontext oder Tool-Metadaten braucht

Ein CLI-Tool ist oft sicherer, weil es nur bei Bedarf aufgerufen wird und nur für diese Runde Output erzeugt. MCP kann sicherer sein, wenn es dir begrenztes OAuth, typisierte Tools und Audit-Logs gibt. Der Fehler ist, MCP reflexartig zu installieren.

Kompaktes Vergleichsdiagramm von CLI-Tools und MCP Servern über vier Zeilen: Kontextkosten, Berechtigungsfläche, Setup

Hooks verdienen ihren eigenen Security-Review

Hooks sind das Feature, durch das Plugins magisch wirken. Sie sind auch das Feature, das ich am härtesten prüfe.

Claude Code Hooks können bei Events wie SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact und SessionEnd laufen. Die Plugin-Referenz sagt, dass Hook-Typen Command-Hooks, HTTP-Hooks, MCP-Tool-Hooks, Prompt-Hooks und Agent-Hooks umfassen (Claude Code plugin reference). Der Hooks-Guide erklärt, dass ein PreToolUse Hook eine Aktion blockieren kann, indem er mit Code 2 beendet, während stdout von UserPromptSubmit, UserPromptExpansion und SessionStart zu Claude’s Kontext hinzugefügt werden kann (Claude Code hooks guide).

Das ist eine Menge Macht.

Ein guter Hook blockiert gefährliches Verhalten oder fügt kompakten, deterministischen Kontext hinzu. Ein schlechter Hook macht aus jedem Prompt eine teure RAG-Pipeline, leakt Prompt-Text an einen HTTP-Endpunkt oder verändert still deine Umgebung.

Prüfe Hooks mit vier Fragen:

Welches Event löst ihn aus?
Welcher Matcher begrenzt ihn?
Welche Daten erhält er?
Was schreibt er nach stdout, stderr, auf die Platte, ins Netzwerk oder in den Kontext?

Die Community ist hier auf nützliche Weise gespalten. In einem r/ClaudeCode-Thread zu Hooks beschreiben manche Entwickler Hooks als den einzigen verlässlichen Weg, Regeln durchzusetzen, schlechte Git-Aktionen zu blockieren oder Claude daran zu erinnern, Memory zu schreiben. Andere bauen ausgefeilte Memory- und RAG-Flows auf UserPromptSubmit (Reddit). Beides kann valide sein. Der Unterschied liegt im Budget und im Blast Radius.

Für Team-Installationen würde ich Policy-Hooks früher erlauben als Kontext-Injection-Hooks. Ein PreToolUse Hook, der rm -rf-Muster blockiert, ist leicht zu verstehen. Ein UserPromptSubmit Hook, der in jeder Runde Memory abruft und injiziert, braucht Messungen, Limits und klare Ownership.

Eng installieren, messen, dann hochstufen

Claude Code unterstützt User-, Project-, Local- und Managed-Plugin-Scopes. Die Docs beschreiben User-Scope als persönlich über Projekte hinweg, Project-Scope als geteilt über .claude/settings.json und Local-Scope als projektspezifisch, aber nicht geteilt (Claude Code docs).

Nutze diese Scopes als Rollout-Mechanismus:

Installiere zuerst lokal.
Führe eine echte Aufgabe aus.
Prüfe /plugin-Details und /mcp.
Nutze /context und /usage vorher und nachher.
Deaktiviere alles, was seine Miete nicht verdient.
Hebe es erst nach Review auf Project-Scope.

Die Docs sagen inzwischen, dass der Plugin-Details-Pane in Claude Code v2.1.143 und neuer geschätzte Kontextkosten anzeigen kann, in v2.1.144 und neuer Datumsangaben zur letzten Aktualisierung und in v2.1.145 und neuer ein „Will install“-Inventar (Claude Code docs). Nutze dieses Inventar, bevor du auf Install drückst. Wenn ein Plugin behauptet, ein Formatter zu sein, aber einen MCP Server, einen Hook und einen Background-Monitor installiert, stopp und prüfe nach.

Achte auch auf Auto-Updates. Anthropic sagt, dass offizielle Marketplaces Auto-Updates standardmäßig aktiviert haben, während Drittanbieter- und lokale Marketplaces standardmäßig deaktiviert sind. Die Docs beschreiben außerdem DISABLE_AUTOUPDATER und FORCE_AUTOUPDATE_PLUGINS, um Update-Verhalten zu steuern (Claude Code docs). Auto-Update ist praktisch für Security-Fixes, verändert aber deine Runtime-Supply-Chain. Für regulierte Teams: Pinne Marketplace-Versionen in einem geprüften internen Marketplace, statt jeden Laptop unabhängig driften zu lassen.

Vorher-nachher-Mockup eines Audit-Dashboards, bei dem das installierte Plugin-Inventar von vielen MCP Servern und Hooks auf

Die Checkliste, die ich vor der Installation nutze

Hier ist die Kurzversion, die ich jedem Entwickler in einem Team geben würde, das Claude Code nutzt.

Quelle:

Ist der Marketplace anthropics/claude-plugins-official, ein internes Repo oder ein Drittanbieter-Repo?
Ist die Plugin-Quelle auf eine SHA gepinnt?
Passt die Homepage zum Source-Owner?
Hat das Repo aktuelle unerwartete Änderungen, generierte Blobs oder Install-Scripts?

Komponenten:

Fügt es MCP Server hinzu?
Fügt es Hooks hinzu?
Fügt es Executables in bin/ hinzu?
Fügt es Agents hinzu, die Tools aufrufen können?
Fügt es LSP-Server hinzu, die lokale Binaries brauchen?

Berechtigungen:

Welche Credentials fordert es an?
Werden sensible Werte über Plugin-userConfig als sensitive Fields gespeichert?
Bekommt der MCP Server Read-only- oder Schreibzugriff?
Telefoniert ein Hook per HTTP nach Hause?
Erbt irgendein Script breite Environment-Variablen?

Kosten:

Welche Kontextkosten meldet /plugin?
Was ändert sich in /context, nachdem du es aktivierst?
Liefert das Plugin in jeder Session Wert oder nur in seltenen Workflows?
Könnte ein CLI-Command dasselbe Ergebnis mit weniger persistentem Kontext liefern?

Betrieb:

Kannst du es sauber mit /plugin disable name@marketplace deaktivieren?
Kannst du es sauber deinstallieren?
Hinterlässt es Config, Credentials, Daemons, Caches oder Browser-Auth?
Wer ist für Updates verantwortlich?
Was bricht, wenn die Plugin-Quelle verschwindet?

Die pointierte Antwort: Installiere weniger Plugins, als du willst. Bevorzuge kleine, langweilige Plugins, die einen einzigen Workflow hinzufügen. Bevorzuge CLIs für einmalige Operationen. Nutze MCP, wenn der Server begrenzt, auditiert und wirklich interaktiv ist. Nutze Hooks für Leitplanken, nicht als Abladeplatz für jede Vorliebe, von der du dir wünschst, dass das Modell sie sich merkt.

Plugins werden zu Claude Code’s Paketformat für Workflows. Das ist gut. Es bedeutet, dass Teams wiederholbare Setups teilen können, statt sich auf Prompt-Folklore zu verlassen. Aber dieses Paketformat ist mächtig genug, um Dependency-Review, Permission-Review und Kosten-Review zu verdienen. Wenn du ein Tool nicht per curl | bash in dein Repo holen würdest, ohne es zu lesen, installiere nicht die Plugin-Version davon, nur weil sie in einer freundlichen Marketplace-UI auftaucht.

Leiser Footer: Wenn du Claude Fable 5 selbst ausprobieren willst, kannst du es über Claude Fable 5 on OneHop nutzen, einen Drop-in-Endpunkt, der etwa 30% unter Listenpreis liegt. Neue Accounts können mit $10 kostenlos starten, keine Karte nötig.

Weiterlesen: Getting started with Claude Fable 5.