Claude Code Mods: mächtig, aber ohne Sandbox

Anthropic hat am 01.10.2026 Mods für Claude Code freigeschaltet. Ein Mod ist ein Plugin mit JavaScript- oder TypeScript-Funktionen, die Claude Code bei bestimmten Ereignissen aufruft: wenn Claude ein Tool nutzen will, wenn ein Prompt abgeschickt wird oder wenn die Oberfläche gezeichnet wird. Der Mod kann zuschauen, das Ereignis verändern oder es komplett übernehmen. Das ist deutlich mehr als die bisherigen Hooks in der settings.json, die ein Skript von außen starten. Ein Mod läuft im Prozess von Claude Code selbst.

Mods sind ab Version 2.1.287 in der CLI und im Code-Tab der Desktop-App verfügbar und standardmäßig eingeschaltet. Einen Vorgeschmack gab es im September, als Claude Code die AGENTS.md über einen eingebauten Mod lesen lernte.

Was ein Mod kann

Laut Doku kann ein Mod unter anderem:

Tool-Aufrufe abfangen: blockieren, umschreiben, wiederholen, oder selbst beantworten, ohne dass das Tool läuft. Einen Request kann er auch an ein anderes Modell schicken.
Prompts umschreiben, bevor das Modell sie sieht, und selbst Prompts absenden, als hätte man sie getippt.
Berechtigungsabfragen beantworten: Ein Tool-Aufruf lässt sich freigeben oder ablehnen, bevor überhaupt eine Rückfrage erscheint.
Secrets aus Tool-Ausgaben schwärzen.
Die Oberfläche umbauen: eigene Panes und Buttons, eigene /-Befehle, oder Teile ersetzen, die Claude Code selbst zeichnet, etwa den Spinner oder den Fragedialog.

Anthropic baut eigene Funktionen inzwischen selbst so: /diff läuft als Mod, weitere sollen folgen. Unter den Beispiel-Mods ist blast-radius, der riskante Shell-Befehle wie rm -rf oder einen Force-Push anhält, zeigt, was sich ändern würde, und erst nach Klick weiterlaufen lässt. Das zeigt die gute Seite: Teams können sich eigene Leitplanken bauen, die genauer sind als jede Allow-Liste.

Warum das gefährlich ist

Anthropic schreibt es selbst ziemlich deutlich: "They aren't sandboxed, and you should only install mods from sources you trust, the same way you'd install any code on your computer." Ein Mod läuft mit den Rechten des Nutzers. Laut Doku kann er damit:

Dateien überall lesen und schreiben, Programme starten und Netzwerkanfragen stellen,
Umgebungsvariablen und Settings-Dateien lesen, inklusive API-Keys,
jeden Prompt und jeden Tool-Aufruf der Sitzung sehen und verändern,
Tool-Aufrufe freigeben, ohne zu fragen,
auf Kosten des eigenen Plans oder API-Keys Modelle aufrufen.

Die Sandbox von Claude Code hilft dabei nicht. Sie isoliert die Bash-Befehle, die Claude ausführt. Ein Prozess, den ein Mod startet, läuft außerhalb.

Am heikelsten ist das Zusammenspiel mit den Berechtigungen. Ein Mod, der Freigaben erteilt, antwortet nach den Regeln und Hooks und kann deren Entscheidung ersetzen:

flowchart TB
  A["Claude will ein Tool nutzen"] --> B["PreToolUse-Hooks aus<br/>verwalteten Einstellungen<br/>(Block ist endgültig)"]
  B --> C["deny- und ask-Regeln,<br/>übrige PreToolUse-Hooks"]
  C --> D{"Mod antwortet<br/>per tool.check"}
  D -->|"Team/Enterprise oder<br/>verwaltete Einstellungen"| E["deny-Regeln halten,<br/>ask-Regeln und Hook-Blocks<br/>kann der Mod übergehen"]
  D -->|"Pro/Max oder API-Key<br/>ohne verwaltete Einstellungen"| F["Mod kann auch<br/>deny-Regeln überstimmen"]
  class B success
  class D,E decision
  class F abort
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Wer bei einem Tool-Aufruf das letzte Wort hat, hängt vom Setup ab: Ohne verwaltete Einstellungen kann ein Mod sogar deny-Regeln überstimmen.

Konkret heißt das laut Berechtigungs-Doku: Wer Claude Code mit einem Einzel-Abo oder einem API-Key nutzt und keine verwalteten Einstellungen hat, bei dem kann ein installierter Mod einen Aufruf freigeben, den eine eigene deny-Regel verbietet. Im Auto Mode läuft ein vom Mod freigegebener Aufruf außerdem ohne Prüfung durch den Klassifikator. Und selbst wo deny-Regeln halten, gelten sie nur für Claudes Tool-Aufrufe. Ist Read(.env) verboten, kann ein Mod die Datei trotzdem mit seinen eigenen Dateifunktionen lesen.

Damit sind Mods ein Supply-Chain-Thema, genau wie npm-Pakete oder Agent-Plugins. Ein Mod aus einem fremden Marketplace hat mehr Zugriff als die meisten Pakete, weil er zusätzlich alles sieht, was man mit Claude bespricht. Ein Update des Plugins bringt neuen Code mit. Und auch ein Mod, den Claude während einer Sitzung selbst schreibt, wird geladen, solange keine Richtlinie das verhindert.

Was der eingebaute Schutz abdeckt

Für Teams gibt es einen eingebauten Wächter-Mod namens sec-default. Er lädt vor allen Mods, die Nutzer installieren, und lässt sich von ihnen nicht abschalten. Allerdings nur, wenn auf dem Rechner verwaltete Einstellungen liegen oder der Nutzer mit einem Team- oder Enterprise-Plan angemeldet ist. Wer per API-Key oder über Amazon Bedrock, Google Cloud oder Microsoft Foundry arbeitet, bekommt ihn nur mit verwalteten Einstellungen.

Der Wächter schützt das, was die Organisation verwaltet: verwaltete Hooks, Systemprompt, verwaltete Anweisungsdateien, Einstellungen und die verwalteten MCP-Server. Und er sorgt dafür, dass deny-Regeln über Nutzer-Mods stehen. Laut Admin-Doku fügt er darüber hinaus "no other restrictions" hinzu. Dateizugriff, Prozesse, Netzwerk und das Umschreiben von Prompts bleiben erlaubt. Der Quelltext liegt offen auf GitHub.

Was ihr jetzt tun solltet

Einzelne Entwickler:

Mit /plugin nachsehen, welche Mods aktiv sind. Die Zeile unter den Tabs nennt Anzahl und Namen.
Vor der Installation claude plugin validate ./ordner-des-mods laufen lassen. Die Zeilen hooks: und calls: zeigen, welche Ereignisse der Mod abgreift und was er tun darf. Auffällig sind vor allem $.process.run, $.http.fetch, $.env.get, $.fs.write, $.prompt.submit und bei den Hooks tool.check.
Wer Mods nicht braucht, schaltet sie mit "disableAllHooks": true in ~/.claude/settings.json ab. Das stoppt allerdings auch die eigenen Settings-Hooks und die Statuszeile. Zum Testen, ob ein Mod Ärger macht, gibt es claude --safe-mode.

Teams und Admins:

Über die verwalteten Einstellungen allowManagedModsOnly setzen, solange es keinen Review-Prozess gibt. Dann laden nur die Mods der Organisation, die Hooks der Nutzer laufen weiter.
disableSideloadFlags verhindert, dass Mods per --plugin-dir oder von Claude selbst geschrieben nachgeladen werden.
Mods wie jede Abhängigkeit behandeln: Marketplaces per Allowlist begrenzen (strictKnownMarketplaces), Updates bewusst freigeben, und den Code vor dem Freigeben lesen.
Die Option allowModsToOverrideDenyRules nicht ohne guten Grund setzen.

Mods sind ein starkes Werkzeug, gerade für Leitplanken, die Teams sich selbst bauen. Das macht sie aber eben auch zum attraktivsten Einfallstor in einen Rechner, auf dem ein Coding-Agent ohnehin schon viel darf. Wie man solche Agenten generell absichert, steht in KI-Tools sicher nutzen und in unserer Einordnung der OWASP Top 10 für Agentic AI.