Claude Code Mods: Was die neuen Erweiterungen können und warum sie mit Ihren Rechten laufen

Ein Werkzeug, das einen KI-Agenten bremsen soll, braucht selbst die Rechte, ihn zu bremsen. Genau das ist der Kern der Mods, die Anthropic am 1. Oktober für Claude Code eingeführt hat. Ein Mod ist ein kleines Programm in JavaScript oder TypeScript, das innerhalb von Claude Code läuft und bei jedem Ereignis gefragt wird: bei jedem Prompt, jedem Werkzeugaufruf, jeder Berechtigungsanfrage, jedem Neuzeichnen der Oberfläche. Er kann zusehen, ändern oder selbst antworten.

Das eröffnet viel. Ein Mod kann einen gefährlichen Befehl anhalten und nachfragen, Geheimnisse aus Ausgaben entfernen oder eine Leiste mit dem Stand der Pipeline einblenden. Er kann aber auch Prompts mitlesen und Werkzeugaufrufe freigeben, ohne dass Sie gefragt werden. Für Betriebe, in denen Entwickler mit Claude Code arbeiten, ist das eine neue Stelle, an der fremder Code mit vollen Rechten läuft.

Wir haben die Dokumentation gelesen, die Beispiel-Mods von Anthropic geprüft und selbst einen kleinen Mod gebaut und getestet.

Offenlegung: Wir arbeiten täglich mit Claude Code und beraten Unternehmen bei der Einführung von KI-Agenten. Mit Anthropic haben wir keine geschäftliche Verbindung außer unseren eigenen Abonnements. Alle Angaben stammen aus dem Ankündigungsbeitrag und der Dokumentation von Anthropic, abgerufen am 21. Oktober 2026. Unsere Tests liefen mit Claude Code 2.1.306.

Was ein Mod ist

Technisch ist ein Mod ein Plugin, also ein Ordner mit einer Beschreibung und einer Code-Datei. Installiert wird er wie jedes Plugin mit /plugin. Der Code meldet beim Laden an, auf welche Ereignisse er reagieren will. Das Beispiel aus der Dokumentation zählt die Werkzeugaufrufe und schreibt die Zahl neben die Statusanzeige. Es ist gut zwanzig Zeilen lang.

Anthropic grenzt Mods von den bisherigen Hooks ab. Hooks sind Skripte, die Claude Code bei bestimmten Ereignissen von außen startet. Sie können einen Aufruf erlauben, blockieren oder protokollieren. Mods laufen dagegen im Programm selbst. Laut Ankündigung können Hooks Ereignisse nicht umschreiben, keine Oberfläche zeichnen und keine eingebaute Funktion ersetzen. Mods können das. Das eingebaute /diff ist inzwischen selbst ein Mod.

Mods laufen im Terminal, in der Desktop-App und in der VS-Code-Erweiterung, außerdem in Sitzungen ohne Oberfläche wie claude -p. Das ist wichtig für Automatisierungen: Ein installierter Mod läuft auch dann, wenn niemand zusieht.

Was ein Mod alles erreicht

Die Dokumentation ist an dieser Stelle ungewöhnlich deutlich. Ein Mod läuft mit den Rechten des Nutzers und kann danach unter anderem Dateien überall lesen und schreiben, wo der Nutzer es kann, Programme starten und Netzwerkanfragen stellen. Er kann Umgebungsvariablen und Einstellungsdateien lesen, „including an API key you keep in either“. Er sieht jeden Prompt und jeden Werkzeugaufruf, kann beides umschreiben, einen Prompt abschicken, als hätten Sie ihn getippt, und einen Werkzeugaufruf freigeben, bevor Sie gefragt werden. Und er kann Modelle auf Ihre Rechnung aufrufen.

Dazu der Satz, den man in Sicherheitsrichtlinien übernehmen sollte: „Mods aren’t sandboxed.“ Wer die Sandbox von Claude Code einschaltet, isoliert die Befehle, die Claude ausführt. Ein Programm, das ein Mod startet, läuft außerhalb.

Eine Grenze hat Anthropic eingezogen: Die Berechtigungsabfrage selbst kann kein Mod umgestalten. Was dort steht, stammt von Claude Code. Ein Mod kann aber vorher entscheiden, dass die Abfrage gar nicht erst erscheint.

Was wir an den Beispielen von Anthropic gesehen haben

Vor der Installation zeigt der Befehl claude plugin validate, welche Ereignisse ein Mod empfängt und welche Funktionen er aufruft, um Dateien, Programme oder das Netz zu erreichen. Wir haben ihn auf die drei Beispiel-Mods angewandt, die Anthropic im Repository claude-code-playground teilt.

Mod	Zweck	Zeilen	Erreicht außerhalb von Claude Code
token-weather	zeigt an, wie voll das Kontextfenster ist	122	nichts
replay-theater	spielt die Dateiänderungen der letzten Runde nach	249	liest Dateien
blast-radius	hält riskante Befehle wie rm -rf an und zeigt die Folgen	528	startet Programme

Die Überraschung steckt in der letzten Zeile. Ausgerechnet der Mod, der für mehr Sicherheit sorgen soll, startet selbst Programme: git, um zu zeigen, was ein Reset oder Force-Push verwerfen würde, eine bash-Shell, um Verzeichnisse aufzulösen, und sogar sleep, um zu warten, bis jemand auf „Weiter“ oder „Abbrechen“ drückt. Das ist nachvollziehbar und im Code offen kommentiert. Es zeigt aber, wie begrenzt die Liste ist: Sie sagt, was ein Mod kann, nicht wofür er es tut. Die Beispiel-Richtlinie aus der Dokumentation für Administratoren lehnt jeden Nutzer-Mod ab, der Programme startet. Nach der Liste würde sie auch blast-radius ablehnen.

Für Betriebe heißt das: claude plugin validate ist ein guter erster Filter. Ein Mod, der nichts außerhalb von Claude Code erreicht, ist schnell eingeschätzt. Sobald in der Liste Dateien, Programme, Netz oder Umgebungsvariablen auftauchen, muss jemand den Code lesen.

Unser eigener Test: ein Mod, der Schlüssel schwärzt

Ein typischer Unfall beim Arbeiten mit Coding-Agenten: Der Agent liest zur Fehlersuche eine .env-Datei oder gibt Umgebungsvariablen aus, und der API-Schlüssel landet im Gespräch mit dem Modell. Wir haben einen Mod geschrieben, der Werkzeugausgaben durchsucht und erkannte Schlüssel durch [GESCHWÄRZT] ersetzt, bevor das Modell sie liest. Er erkennt Schlüssel von Anthropic und OpenAI, GitHub-Token, AWS-Zugangsschlüssel und private Schlüssel im PEM-Format. Der Mod hat 39 Zeilen.

Getestet haben wir ihn mit claude plugin test. Das Testwerkzeug spielt Ereignisse durch, ohne Sitzung, ohne Anmeldung und ohne einen einzigen Modellaufruf. Sechs Tests, alle grün:

Fall	Ergebnis
.env mit Anthropic- und AWS-Schlüssel per cat ausgegeben	beide geschwärzt
privater SSH-Schlüssel per Read gelesen	geschwärzt, Text davor und danach bleibt
harmlose Ausgabe von ls	unverändert
Zähler per eigenem Befehl /geschwaerzt	zählt richtig
derselbe Schlüssel base64-kodiert	geht durch
derselbe Schlüssel auf zwei Zeilen verteilt	geht durch

Die beiden letzten Zeilen sind Absicht. Wir haben sie als Grenzen festgeschrieben, weil ein Filter nach Mustern genau das nicht leisten kann. Ein Agent, der einen Schlüssel kodiert oder zerlegt ausgibt, umgeht ihn. Ein Mod dieser Art fängt Versehen ab, keinen Angreifer.

Zur Gegenprobe haben wir die Schwärzung im Code ausgeschaltet. Dann schlugen genau die drei Tests fehl, die fehlschlagen müssen. Ein Test, der nie rot werden kann, prüft nichts.

Zwei Dinge haben uns positiv überrascht. claude plugin validate meldet für unseren Mod „calls: nothing on $“: Er erreicht nichts außerhalb von Claude Code, und das lässt sich ohne Codelesen feststellen. Und das Werkzeug warnt, wenn ein Mod, der Aufrufe zurückhalten kann, keine Fehlerbehandlung hat. Fällt ein solcher Mod ohne sie aus, überspringt Claude Code ihn, und der Aufruf geht ungeprüft weiter. Unser Filter hält die Ausgabe in diesem Fall zurück. Bei zwei der drei Beispiel-Mods von Anthropic meldet das Werkzeug diese Warnung.

Was der eingebaute Schutz leistet und für wen

Anthropic liefert einen Schutz-Mod namens sec-default mit. Er lädt vor allen Mods, die ein Nutzer installiert, und verhindert unter anderem, dass ein Nutzer-Mod den Systemprompt, die verwalteten Anweisungen oder die verwalteten Hooks einer Organisation verändert. Außerdem haben dann Ablehnungs- und Nachfrageregeln Vorrang: Ein Nutzer-Mod kann keinen Aufruf freigeben, den eine deny-Regel sperrt oder bei dem eine ask-Regel nachfragen würde.

Der Haken steht eine Zeile darüber. Der Schutz lädt nur, wenn der Rechner verwaltete Einstellungen hat oder die Sitzung mit einem Team- oder Enterprise-Login läuft. Wer mit einem privaten Pro- oder Max-Konto arbeitet oder mit einem API-Schlüssel, hat ihn nicht. Dort kann ein Mod laut Dokumentation auch Aufrufe freigeben, für die eine ask-Regel sonst nachfragen würde, oder die ein PreToolUse-Hook blockiert hat. Das ist dieselbe Lücke, die wir schon bei Schatten-KI beschrieben haben: Der Mitarbeiter mit dem privaten Konto arbeitet ohne die Leitplanken der Firma.

Auch mit Schutz gilt: Ablehnungsregeln wirken auf die Werkzeugaufrufe von Claude, nicht auf die eigenen Datei- und Prozessaufrufe eines Mods. Ist Read(.env) verboten, kann ein Mod die Datei trotzdem selbst lesen. Und wer im Auto-Modus arbeitet, sollte wissen, dass ein Aufruf, den ein Mod freigibt, in der Regel ohne die übliche Prüfung durch den Klassifikator läuft.

Was ein Betrieb einstellen sollte

Erstens: festlegen, wer überhaupt Mods installieren darf. Für Firmen, die Claude Code über Team oder Enterprise nutzen, gibt es dafür eine Einstellung im Schutz-Mod. In den verwalteten Einstellungen sieht sie so aus:

{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": { "allowManagedModsOnly": true }
    }
  },
  "disableSideloadFlags": true
}

Die erste Option lässt nur Mods der Organisation und die eingebauten laufen. Die zweite sperrt das Laden aus beliebigen Ordnern mit --plugin-dir und verhindert, dass Mods geladen werden, die Claude während einer Sitzung selbst schreibt. Das ist kein theoretischer Fall: Claude Code bringt eine Anleitung mit, mit der Claude auf Zuruf Mods baut. Beide Optionen wirken nur aus den verwalteten Einstellungen. Ein Nutzer kann sie in seinen eigenen Dateien nicht aufheben.

Zweitens: Mods vor der Freigabe prüfen. claude plugin validate zeigt die Ereignisse und Aufrufe. Wer Prompts oder Werkzeugaufrufe sieht und gleichzeitig ins Netz darf, könnte beides nach außen schicken. Das muss nicht böse gemeint sein, verdient aber einen Blick in den Code.

Drittens: private Konten aus der Arbeit mit Firmencode herausnehmen. Ohne Team- oder Enterprise-Login und ohne verwaltete Einstellungen fehlt der Schutz-Mod ganz.

Viertens: bei seltsamem Verhalten claude --safe-mode kennen. Damit startet Claude Code ohne installierte Mods, und man sieht schnell, ob einer der Grund ist.

Wer weitergehen will, kann einen eigenen Richtlinien-Mod schreiben, der vor allen anderen lädt, jeden Mod vor dem Laden prüft und Werkzeugaufrufe protokolliert. Die Dokumentation enthält dafür ein vollständiges Beispiel mit Tests. Das ist dieselbe Idee, die wir mit AgentGuard für KI-Agenten außerhalb von Claude Code umsetzen: Eine Stelle, an der jede Aktion vorbeimuss, bevor sie passiert.

Was offen bleibt

Mods sind drei Wochen alt. Die Versionsnummern, ab denen einzelne Funktionen gehen, ändern sich laufend, und einiges in der Dokumentation ist mit Mindestversionen versehen. Ob Anthropic für das Plugin-Verzeichnis eine eigene Prüfung von Mods einführt, die über die automatischen Checks hinausgeht, steht dort nicht. Der Validator weist selbst darauf hin, dass das Verzeichnis eigene Regeln für Mod-Code hat, die er nicht anwendet.

Für den Alltag ändert das wenig. Ein Mod ist installierte Software mit vollen Rechten und Einblick in jedes Gespräch mit dem Agenten. So sollte man ihn behandeln. Mehr zu Leitplanken für Coding-Agenten steht in Agentic Coding im Mittelstand, zur Gefahr durch untergeschobene Anweisungen in Prompt Injection.

Wenn Sie Claude Code im Team einsetzen und eine Richtlinie für Plugins und Mods brauchen, die Entwickler nicht ausbremst, sprechen Sie uns an.

Quellen

Alle abgerufen am 21.10.2026.

• Anthropic: Customize Claude Code with mods in TypeScript, 01.10.2026
• Claude Code Docs: Mods overview (Fähigkeiten, „What a mod can reach“, eingebaute Mods)
• Claude Code Docs: Manage mods for your organization (sec-default, allowManagedModsOnly, disableSideloadFlags, Richtlinien-Mod)
• Claude Code Docs: Test a mod
• GitHub: anthropics/claude-code-playground, claude-code/mods (Beispiel-Mods, Stand 01.10.2026)
• GitHub: anthropics/claude-code, mods (Quelltext der eingebauten Mods, darunter sec-default)

Stand: 21. Oktober 2026. Wenn Anthropic die Regeln für Mods im Plugin-Verzeichnis veröffentlicht oder den Schutz auf Einzelkonten ausweitet, ergänzen wir den Beitrag.