Claude Code Mods erklärt: JavaScript-/TypeScript-Plugins, Beispiele und sicherer Einsatz

Claude Code Mods machen Claude Code programmierbar. Seit dem 1. Oktober 2026 können kleine JavaScript- oder TypeScript-Funktionen direkt im Prozess von Claude Code mitlaufen: Sie sehen jeden Prompt und jeden Tool-Aufruf, können beides ändern oder stoppen und eigene Bereiche in der Oberfläche anzeigen, z. B. ein Panel neben dem Chat.

Stand: 14.10.2026, aktuelle Version Claude Code v2.1.296.

Das ist mächtig, und genau deshalb lohnt sich ein genauer Blick darauf, wo Mods hingehören und wo nicht. Dieser Artikel ordnet Mods gegenüber Hooks, Skills und MCP-Servern ein, zeigt die wichtigsten Muster aus der offiziellen Dokumentation und erklärt, worauf es beim sicheren Einsatz ankommt.

Was sind Claude Code Mods?

Ein Mod ist ein Claude Code-Plugin mit einem sogenannten Hooks-Modul: einer JavaScript- oder TypeScript-Datei, die eine Funktion register exportiert. Darin meldet der Mod über on(...) an, bei welchen Ereignissen Claude Code ihn aufrufen soll, etwa wenn Claude gleich ein Tool verwendet (tool.call), wenn ein Prompt abgeschickt wird (prompt.submit) oder wenn ein Teil der Oberfläche gezeichnet wird (ui.render).

Laut Ankündigung von Anthropic können Mods unter anderem:

• einen Prompt umschreiben, bevor er beim Modell ankommt
• einen Tool-Aufruf blockieren, umschreiben oder wiederholen
• eine Berechtigungsanfrage genehmigen oder ablehnen
• Geheimnisse aus Tool-Ergebnissen schwärzen, bevor Claude sie liest
• Teile der Oberfläche ändern oder ersetzen und eigene Schaltflächen und Eingabefelder hinzufügen

Einige eingebaute Funktionen von Claude Code sind selbst als Mod umgesetzt, etwa /diff.

Wo Mods laufen: Mods brauchen im Terminal Claude Code ab v2.1.287 und in der Desktop-App (Code-Tab) ab v2.1.286; dort sind sie standardmäßig aktiv. Die Version zeigt claude --version bzw. /status in der Desktop-App. Hooks laufen in jeder Sitzung, die das Plugin lädt, also auch in VS Code, mit claude -p, im Agent SDK und in Cloud-Sessions. Eigene Oberflächen erscheinen nur im Terminal und im Code-Tab der Desktop-App.

Claude Code Mods vs. Hooks, Skills und MCP-Server

Die vier Erweiterungswege überschneiden sich. Die Dokumentation grenzt sie so ab:

Faustregel: Reicht eine feste Berechtigungsregel wie Bash(npm test) oder ein vorhandenes Skript als Hook, ist ein Mod unnötig. Einstellungs-Hooks können Tool-Aufrufe erlauben, blockieren und deren Argumente ändern; Prompts, Modellanfragen und die Oberfläche umschreiben kann nur ein Mod.

Wie ein Mod aufgebaut ist

Ein minimaler Mod besteht aus drei Dateien:

mein-mod/
├── .claude-plugin/
│   └── plugin.json
└── hooks/
    ├── hooks.json
    └── register.js

plugin.json ist das Manifest, hooks.json verweist mit dem Schlüssel modules auf den Code, und register.js enthält die Hooks. Node.js, ein Bundler oder ein Build-Schritt sind nicht nötig, weil Claude Code .js- und .ts-Dateien direkt lädt. Die Hooks eines Mods teilen sich Variablen; nach einem Neuladen beginnen diese wieder bei null.

Jeder Hook erhält drei Argumente: $ ist die Schnittstelle für alles, was ein Mod tun darf; e beschreibt das Ereignis; next(e) gibt es an den nächsten Mod bzw. an Claude Code weiter. Daraus ergeben sich drei Verhaltensweisen:

1. Beobachten: Arbeit erledigen und next(e) zurückgeben.
2. Umschreiben: next mit einer geänderten Kopie des Ereignisses aufrufen, zum Beispiel mit bereinigtem Prompt-Text.
3. Selbst erledigen: Der Mod liefert das Ergebnis, ohne next aufzurufen. Claude Code führt die Aktion dann nicht aus, und auch spätere Mods laufen nicht.

Beispiel: einen Tool-Aufruf blockieren

Dieses Beispiel aus der Dokumentation zu Ereignissen lehnt Force-Pushes ab und sagt Claude, was stattdessen zu tun ist:

on('tool.call', { tool: 'Bash' }, async ($, e, next) => {
  if (/git push .*--force/.test(e.command)) {
    return { deny: 'Force pushes are not allowed in this repository. Push to a new branch instead.' }
  }
  return next(e)
})

Claude liest den deny-Text, als wäre er die Ausgabe des Tools. Er sollte deshalb als Anweisung formuliert sein, mit der Claude weiterarbeiten kann. Statt hart abzulehnen, kann ein Hook auch mit $.ui.ask nachfragen und den Aufruf so lange zurückhalten, bis der Benutzer entschieden hat, ein klassisches Human-in-the-Loop-Muster. Anthropic stellt dafür den Beispiel-Mod blast-radius bereit, der riskante Befehle wie rm -rf anhält und zeigt, was sie ändern würden.

Die Dokumentation weist selbst auf die Grenze dieses Musters hin: Ein regulärer Ausdruck über den Befehlstext übersieht andere Schreibweisen, etwa git push -f. Ein solcher Hook ist eine Erinnerung für Claude, kein Ersatz für einen geschützten Branch beim Git-Host.

Was Claude Code Mods für die Sicherheit bedeuten

Der wichtigste Satz steht in der Ankündigung: Mods laufen mit demselben Zugriff auf den Rechner wie Claude Code selbst und sind nicht in einer Sandbox. Ein geladener Mod kann laut Dokumentation:

• Dateien lesen und schreiben, Programme starten und Netzwerkanfragen stellen
• Umgebungsvariablen und Einstellungsdateien lesen, inklusive dort abgelegter API-Schlüssel
• jeden Prompt und jeden Tool-Aufruf sehen und umschreiben
• Tool-Aufrufe genehmigen, bevor der Benutzer gefragt wird, auch solche, für die eine ask-Regel nachfragen würde
• über den eigenen Plan oder API-Schlüssel ein Modell aufrufen

Auch aktiviertes Sandboxing ändert daran nichts: Die Sandbox isoliert die Bash-Befehle, die Claude ausführt, nicht aber Prozesse, die ein Mod startet. Laut Admin-Dokumentation kommen weitere Punkte hinzu:

• Deny-Regeln gelten nicht für die eigenen Zugriffe eines Mods. Datei- und Prozesszugriffe über $.fs und $.process sind davon ausgenommen. Ein Mod kann eine per Read(.env) gesperrte Datei trotzdem lesen.
• Ohne sec-default kann ein Mod unter Umständen Aufrufe genehmigen, die eine Deny-Regel verbietet.

Eine technische Grenze: Den Berechtigungsdialog selbst kann ein Mod nicht umgestalten. Wie Organisationen Mods zusätzlich einschränken, steht im Abschnitt „Mods ausschalten und im Team steuern“.

AI Weekly ordnet das in einem Meinungsbeitrag als Lieferketten-Risiko für Unternehmen ein. Die Konsequenz ist dieselbe wie bei jeder anderen Software: Mods nur aus vertrauenswürdigen Quellen installieren und vorher prüfen.

Einen Mod vor der Installation prüfen

Weil ein Hook alles, was über seinen eigenen Code hinausgeht, über die Mods-API erledigen muss, kann Claude Code statisch auflisten, was ein Mod tut. Nach dem Klonen des Repositorys reicht:

claude plugin validate ./ein-mod

Die Zeile hooks: zeigt, auf welche Ereignisse der Mod reagiert, die Zeile calls:, welche Methoden der Mods-API er aufruft. Ein Mod, der angeblich nur eine Anzeige zeichnet, aber Prozesse startet oder Netzwerkanfragen stellt, verdient einen zweiten Blick. Für eigene Mods gibt es zusätzlich claude plugin test, das Hooks ohne Sitzung, Anmeldung und Netzwerk testet.

Fail-open vermeiden: Wächter-Mods richtig bauen

Ein Detail ist für alle wichtig, die Mods als Schutzmechanismus (Guardrails) einsetzen wollen: Wirft ein Hook eine Ausnahme oder überschreitet er sein Zeitlimit, bevor er next aufgerufen hat, überspringt Claude Code ihn, und der Aufruf läuft weiter, als gäbe es den Mod nicht. Bei einem Fehler lässt ein Wächter-Mod den Befehl standardmäßig also durch („fail-open“).

Die Dokumentation zeigt, wie ein Hook stattdessen sicher scheitert. on gibt eine Registrierung zurück, an die sich ein Fehlerhandler hängen lässt:

on('tool.call', { tool: 'Bash' }, guard).catch(async ($, e, next) => {
  // guard hatte next schon aufgerufen: dessen Ergebnis zurückgeben
  if (next.called) return next(e)
  return { deny: 'The command guard failed, so this command was not run: ' + next.error.kind }
})

Die Zeile mit next.called ist wichtig: Ohne sie würde deny bei einem Fehler nach next nur das Ergebnis eines bereits ausgeführten Befehls verbergen. next.error.kind nennt den Grund, z. B. throw oder timeout. Scheitert auch der .catch-Handler, wird der Hook trotzdem übersprungen.

Bei zurückgehaltenen Aufrufen gilt dasselbe Prinzip: Wartezeit innerhalb von $.ui.ask zählt nicht auf das Zeitlimit, eigenes Warten schon. Läuft das Limit ab, wird der Hook übersprungen und der Befehl ausgeführt.

Das passt zu dem Prinzip, nach dem ich meinen n8n MCP Server mit minimalen Rechten gebaut habe: Grenzen technisch durchsetzen, statt sich auf Anweisungen an das Modell zu verlassen, und dabei auch den Fehlerfall bedenken. Ein Mod im Client und eng geschnittene Werkzeuge auf dem Server ergänzen sich: Der Mod fängt ab, was Claude versucht, der Server begrenzt, was technisch überhaupt möglich ist. Wie solche Werkzeuge für eine Wissensbasis aussehen, zeigt das Projekt RAG-Wissensbasis mit MCP-Server.

Mods ausschalten und im Team steuern

Für einzelne Personen gibt es drei Schalter: einen Mod im Tab Installed von /plugin deaktivieren, alle installierten Mods für eine Sitzung mit --safe-mode abschalten oder dauerhaft "disableAllHooks": true in ~/.claude/settings.json setzen. Dabei gilt:

• --safe-mode schaltet auch andere Anpassungen ab.
• disableAllHooks stoppt auch die eigenen Einstellungs-Hooks und die Statuszeile, aber nur den Mod-Teil eines Plugins; Skills und MCP-Server desselben Plugins laden weiter.
• Eingebaute Mods stoppen weder --safe-mode noch disableAllHooks.

In Organisationen greifen zusätzliche Mechanismen:

• Hooks, die die IT zentral vorgibt (Managed Settings) und die vor jedem Tool-Aufruf laufen, kommen vor jedem Mod, und ihre Blockierung ist endgültig.
• Auf Team- und Enterprise-Plänen sowie auf jedem Rechner mit verwalteten Einstellungen lädt zuerst der eingebaute Mod sec-default. Er hindert von Benutzern installierte Mods an riskanten Aktionen, etwa daran, Deny-Regeln zu übergehen.
• Über dessen Option allowManagedModsOnly (in den Managed Settings unter pluginConfigs) lassen sich von Benutzern installierte Mods ganz abschalten. Über prependPlugins und appendPlugins legen Administratoren fest, wo eigene Richtlinien-Mods in der Kette stehen.

Lohnen sich Claude Code Mods?

Für Teams, die Claude Code täglich einsetzen, ja, vor allem für Dinge, die bisher nur mit Disziplin funktionierten: Bestätigung vor Änderungen an Produktionskonfiguration, ein sichtbarer Status der CI-Pipeline neben dem Gespräch oder ein Protokoll aller Tool-Aufrufe. Wer nur ein Skript bei einem Ereignis ausführen will, bleibt mit einem Hook aus der settings.json einfacher. Wie solche Hooks einen Agenten mit heiklen Werkzeugen absichern, zeige ich am Beispiel Reverse Engineering mit Claude und Ghidra MCP.

Der Einstieg ist niedrigschwellig: Claude kann einen Mod über den eingebauten Skill plugin-authoring selbst schreiben, er wird nach Freigabe in der laufenden Sitzung geladen und bei Änderungen neu geladen. Weil sich Ereignisse und Methoden zwischen Releases ändern können, empfiehlt Anthropic, bei Unklarheiten den Typdefinitionen zu vertrauen, die Claude Code beim Entwickeln eines Mods in dessen Ordner .claude-plugin/types/ schreibt.