Claude Mods: Was das neue Plugin-Format in Claude Code wirklich darf

Am 1. Oktober 2026 hat Anthropic Claude Code 2.1.287 veröffentlicht. Der Changelog-Eintrag dazu ist ein Nebensatz: "Added Claude Mods: plugins may now modify deeper behavior." Die Videos zum Feature nennen es eines der größten Updates, die Claude Code bisher bekommen hat. Das Erklärvideo von Tristen O'Brien vom 5. Oktober führt fünf selbst gebaute Mods vor: eine Checklistendarstellung ohne die Tool-Aufrufe, einen Modell- und Effortschalter, ein Dock für parallele Helfer-Agents, ein Foto- und Videostudio, das den bezahlten Dienst Higgsfield anbindet, und ein Rennspiel für die Wartezeit. Der Kanal weist Higgsfield als Sponsor aus.

Für jemanden, der Claude Code auf Rechnern seiner Abteilung laufen hat, ist die Frage eine andere. Was läuft da künftig auf den Geräten, wer darf es einbauen, und wie bekommt man es wieder weg? Die Antwort steht vollständig in der Doku, und sie ist konkreter als jedes Demo. Wer das Werkzeug schon länger im Teamalltag nutzt, findet die Randbedingungen bei Claude Code im Praxiseinsatz beschrieben.

Was ein Mod technisch ist

Ein Mod ist ein Plugin. Das Verzeichnis braucht eine .claude-plugin/plugin.json, ein hooks/hooks.json mit einem Pfad im Feld modules, und ein JavaScript- oder TypeScript-Modul, das register(on, options) exportiert. Dort wird jede Funktion, die etwas tun soll, mit on auf einen Eventnamen registriert, etwa on('tool.call', { tool: 'Bash' }, async ($, e, next) => next(e)). Der Handler bekommt vier Dinge: die Mods-API $ mit allen Methoden, das Event als tief eingefrorene Daten, den nächsten Handler next und ein Abortsignal. Der Ablauf ist Middleware.

Pro Event hat der Handler drei Möglichkeiten. Er beobachtet das Event und reicht es weiter, er verändert es, indem er eine Kopie an next übergibt, oder er beantwortet es selbst, womit das erwartete Verhalten von Claude Code gar nicht mehr läuft.

Ein Detail daran ist für die Prüfung wichtiger, als es aussieht. Ein Mod zeichnet nur dort, wo gezeichnet werden kann, also im Terminal und im Code-Reiter der Desktop-App. Im Chat-Panel der VS-Code-Erweiterung und bei claude -p führen die Hooks aus, zeichnen aber nichts, und unter WSL werden Plugins gar nicht geladen. Ein Mod kann das Modell und die Tool-Aufrufe also in einer Umgebung verändern, in der niemand eine Oberfläche davon sieht.

Standardmäßig an, vier Tage alt, und das Changelog ist ehrlich

Mods sind ab 2.1.287 standardmäßig aktiviert. Die Umgebungsvariable aus der frühen Testphase wird seit dieser Version ignoriert, wer sie auf 0 setzt, hält Mods nicht ab.

Die Versionsspirale ist schnell. npm nennt 2.1.283 am 25. September, 2.1.287 am 1. Oktober um 16:59 UTC, 2.1.289 am 3. Oktober und 2.1.290 am 5. Oktober. In den Fixes von 2.1.289 stehen zwei Zeilen, die man als Betreiber gelesen haben sollte. Die erste: "Fixed a deny or ask rule on a nested part of a compound shell command not holding over a user-installed mod's approval on managed machines." Auf Deutsch: In 2.1.287 und 2.1.288 hielt eine deny- oder ask-Regel gegen die Freigabe eines Nutzer-Mods nicht, auf einem verwalteten Rechner. Die zweite: Ein user-installiertes Plugin konnte die Beschreibungen der Anmelde-Tools eines org-verwalteten MCP-Servers umschreiben, also den Text, den ein Nutzer beim Login zu lesen bekommt.

Beides ist vier Tage nach dem Feature behoben. Wer 2.1.287 ausgerollt hat, hatte diese Lücke, und die Behebung ist versionengebunden.

Was ein Mod darf

Die Doku formuliert ohne Beschönigung: "A mod is code that runs with your permissions." Ausdrücklich zugestanden wird einem Mod Folgendes:

• Er handelt mit den Rechten des Nutzers, liest und schreibt Dateien, startet Prozesse und geht ins Netzwerk.
• Er liest Geheimnisse, weil er Umgebungsvariablen und die Settingsdateien sieht, bis hinauf zum API-Schlüssel.
• Er sieht die Sitzung, jeden Prompt, jede Modellantwort, jeden Tool-Aufruf.
• Er verändert die Sitzung, indem er Prompts und Tool-Aufrufe umschreibt, einen Prompt einreicht, als hätte ihn der Nutzer getippt, eine Anfrage an ein anderes Modell schickt oder eine Nachricht an eine andere Sitzung sendet.
• Er genehmigt einen Tool-Aufruf, bevor der Nutzer überhaupt gefragt wurde.
• Er verbraucht Nutzung, weil er das Modell des Plans oder des API-Schlüssels aufrufen darf.

"Nicht sandboxed" steht dort als eigener Absatz, mit einer Präzisierung, die häufig überlesen wird. Die Sandbox von Claude Code isoliert die Bash-Befehle von Claude. Ein Prozess, den ein Mod über $.process.run startet, läuft außerhalb davon.

Der schärfste Satz der Doku richtet sich an alle, die schon Berechtigungsregeln gebaut haben. Ein verweigertes Read(.env) schützt nicht, weil ein Mod dieselbe Datei mit $.fs.read lesen kann. Verweigerte deny-Regeln und verwaltete PreToolUse-Hooks haben Vorrang vor der Genehmigung eines Mods, aber nur bei Tool-Aufrufen von Claude selbst, nicht bei den $.fs- und $.process-Aufrufen des Mods. Ein Mod darf außerdem eine Anfrage genehmigen, für die eine ask-Regel den Nutzer fragen würde, oder eine, die ein PreToolUse-Hook aus nicht verwalteten Settings blockiert hat. Im auto-Modus läuft eine so freigegebene Anfrage ohne den Befehls-Classifier weiter. Eine Grenze nennt die Doku auch: Ein Mod darf die Genehmigungseingabe nicht umschreiben, Auswahl und Text dort bleiben unangetastet.

Der Guard und die Falle im eigenen Policy-Mod

Auf einem verwalteten Rechner und bei Anmeldung mit einem Team- oder Enterprise-Plan lädt Claude Code einen eingebauten Mod namens sec-default@builtin, und zwar vor jedem Mod, den ein Nutzer mitbringt. Er hat die höhere Prioritätsstufe, er kann fremde Mods verweigern, und er setzt zwei Optionen um. allowManagedModsOnly auf true hält jeden mitgebrachten Mod vom Laden ab, auch einen, den Claude in einer Sitzung selbst geschrieben hat. allowModsToOverrideDenyRules auf false verbietet es einem Mod, eine Anfrage zu genehmigen, die gegen eine deny-Regel oder einen verwalteten PreToolUse-Hook verstößt.

Die Grenze dieses Guards steht in einem Halbsatz und entscheidet viel. Bei einer Anmeldung mit einem API-Schlüssel oder über Amazon Bedrock, Google Cloud Agent Platform oder Microsoft Foundry lädt der Guard nur, wenn auf dem Gerät überhaupt verwaltete Einstellungen existieren. Eine Organisation, die keine verwalteten Einstellungen ausliefert, hat keinen Guard, unabhängig davon, was einzelne Nutzer in ihren Dateien einstellen.

Wer selbst einen Policy-Mod bauen will, um fremde Mods zu prüfen, bekommt in der Doku ein Muster von 14 Zeilen. Der Haken steht im selben Abschnitt und ist eine der wenigen Stellen, an denen Claude Code ein Sicherheitsverhalten standardmäßig offen lässt. Ein Hook, der eine Ausnahme wirft, reicht das Event an den nächsten Handler weiter. Ein Prüfmod, der abstürzt, lässt also genau das durch, was er stoppen sollte. Deshalb braucht jeder Policy-Mod einen .catch-Handler mit Veto:

module.exports.register = function register(on) {
  on('plugin.register', { pluginId: '*' }, blockUnauditedProcess({ config: CONFIG }))
    .catch((err, $, e) => ({ Veto: `checker failed: ${e.message}` }));
};

Zwei weitere Hebel bleiben. disableSideloadFlags auf true lehnt --plugin-dir und --plugin-url ab, ohne dass ein Nutzer überhaupt laden kann. disableAllHooks auf true deaktiviert in einer laufenden Sitzung alles Hook-Management, allerdings auch die Hooks aus den Settingsdateien, die nichts mit Mods zu tun haben.

Vor der Installation lesen

claude plugin validate <ordner> führt nichts aus und druckt trotzdem zwei Listen: unter hooks: die Events, die das Modul behandelt, und unter calls: alle Mods-API-Aufrufe, auch die aus einer Funktion, die in einer Registry registriert wird. Mit --strict werden Warnungen zu Fehlern, mit --json kommt ein Report für eine Pipeline. claude plugin test läuft die .test.ts-Dateien des Mods und endet mit Status 1, wenn eine scheitert.

Diese Liste ist eine Inventur und kein Sicherheitsnachweis. Sie sagt nicht, was ein gelisteter $.process.run-Aufruf auf dem Rechner anrichtet. Gelesen haben wir zusätzlich, warum man ihr trauen kann. Das Modul läuft in einem eigenen Container ohne Node-Zugriff, ohne fs, Buffer und process und ohne dynamisches import(), und Claude Code lehnt das Laden eines Mods ab, dessen Benutzung der Mods-API dieser Befehl nicht lesen kann. Ein Mod, der seine Fähigkeiten versteckt, ist damit architektonisch ausgeschlossen, und was in der Liste steht, ist die ganze Fläche.

Was wir auf eigenen Rechnern gemessen haben

Wir haben am 5. Oktober 2026 read-only über SSH nachgeschaut. Im code-server-Container auf unserer Appliance (VM 116, 192.168.180.206) läuft Claude Code 2.1.283, auf dem Host librechat-pve6 (192.168.180.2) steht 2.1.199. Beide liegen unter der Schwelle von 2.1.287, Mods sind dort noch nicht verfügbar. Auf beiden Rechnern existiert kein /etc/claude-code/managed-settings.json, auf der dsh-Box steht gar kein Claude-Code-Binary. Das Inventurdossier unter docs/stack-inventory/inventory.md von Stand 7. September nennt Claude Code gar nicht, die Versionsschicht für dieses Tool wurde bisher nie erfasst.

Damit ist heute nichts zurückzubauen. Das ändert sich mit dem nächsten Update, das ein Entwickler selbst mitnimmt, weil Mods dann standardmäßig kommen und wir keine verwalteten Einstellungen ausliefern. Uns fehlen zwei unspektakuläre Dinge: ein Inventurblatt über die Versionen der Agent-CLI auf den Geräten, die wir sehen können, und die Frage, wer verwaltete Einstellungen ausrollt. Mehrere dieser CLIs auf denselben Geräten ist inzwischen der Normalfall, siehe den Überblick über die Agenten-Werkzeuge 2026. Notebooks, an die wir von hier nicht herankommen, sind von dieser Messung nicht abgedeckt. Genau das ist der Punkt.

Die Modellumschalter, Panels und Spiele aus den Videos sind die Folge des Formats. Der Teil, der uns angeht, ist, dass ein zwanzigzeiliges JavaScript-Modul Dateien lesen darf, die im Kontext eines Nutzers nie vorgekommen wären, und dass dieses Modul eine offiziell unterstützte Bauweise für Claude Code ist. Freigabe oder Verbot ist eine Entscheidung, die man erst treffen kann, wenn Versionen bekannt sind und verwaltete Einstellungen existieren.

Weiterführende Quellen

• Claude Code Changelog, Einträge 2.1.287 bis 2.1.290
• Versionen und Zeitstempel in der npm-Registry
• Mods overview, Vergleich mit Hooks, Skills und MCP-Servern
• Manage mods for your organization, Guard, Optionen und Policy-Mod
• Mods reference, Events, Methoden und Limits
• Claude Code Mods: a field guide, Praxisfälle eines Mod-Autors, im frühen Teil bereits veraltet
• Beispielmods von Anthropic