Claude Code bekommt Mods. Damit verschiebt sich die Erweiterung von der Prompt-Ebene in den Ablauf selbst. Ein Mod ist kein weiterer Textbaustein, den ein Modell irgendwie befolgt. Es ist ein Plugin mit einem Hooks-Modul. Dieses Modul registriert sich an Ereignissen der Engine und entscheidet dann begrenzt, was vor dem nächsten Schritt passieren soll.
Ein Hook sitzt zwischen dem Ereignis der Engine und dem nächsten Schritt. So bleibt Erweiterung ein Teil der Ausführung.
Ereignis
Ein Mod registriert sich an einem Engine-Ereignis.
Regel
Der Hook kann prüfen, ergänzen oder an den nächsten Handler weitergeben.
Wirkung
Tool-Aufruf, Oberfläche oder Agentenauftrag bleiben nachvollziehbar im Ablauf.
Quelle: Claude Code Mods README, Stand 05.10.2026.
was neu ist
Anthropic nennt die technische Grundlage Function Hooks. Im offiziellen Mods-Repository steht das Prinzip knapp: Ein Mod exportiert einen Einstiegspunkt register(on, options). Die registrierten Funktionen bekommen den Engine-Kontext, das Ereignis und eine next-Fortsetzung. Damit können Erweiterungen den Ablauf nicht nur beobachten, sondern an klaren Stellen erweitern.
Das ist ein anderer Hebel als eine dauerhafte Projektanweisung. Eine Anweisung erklärt dem Modell, wie es arbeiten soll. Ein Mod kann dagegen an einer Stelle prüfen, ob ein Werkzeugaufruf in den erlaubten Rahmen fällt, eine Information ergänzen oder eine Oberfläche um einen kleinen, nachverfolgbaren Zustand erweitern.
was bereits eingebaut ist
Das offizielle Repository dokumentiert vier Mods, die mit Claude Code ausgeliefert werden: sec-default schützt verwaltete Organisationsregeln vor nachträglich installierten Plugins. diff versorgt den Befehl /diff mit einer laufend aktualisierten Ansicht der nicht gespeicherten Änderungen. telemetry ergänzt die interne Erfassung, sofern Telemetrie eingeschaltet ist. agents-md kann AGENTS.md als Projektanweisung laden.
Die wichtige Grenze bleibt: Erweiterbarkeit ist kein Freifahrtschein. Ein Mod sollte eine eng beschriebene Aufgabe übernehmen, seine Rechte klein halten und sich wie jeder andere Teil des Entwicklungsablaufs testen lassen.
die entscheidende grenze: ergänzen oder bestimmen
Die eingebaute Sicherheits-Schicht sec-default zeigt, worauf es ankommt. Sie sitzt in verwalteten Team- und Enterprise-Umgebungen außen in der Kette und sorgt dafür, dass persönliche Plugins keine bereits festgelegten Organisationsregeln, Prompt-Inhalte oder Tool-Policies aushebeln. Ein eigener Mod ist also kein Ersatz für eine zentrale Sicherheitsvorgabe. Er ist eine Erweiterung innerhalb eines klaren Rahmens.
Je weiter ein Mod den Ablauf verändern darf, desto klarer müssen Regel, Test und verantwortliche Person sein.
Beobachten
Ereignisse sichtbar machen, ohne den Ablauf zu verändern.
Hinweisen
Eine begründete Prüfung ergänzen, bevor ein Schritt weiterläuft.
Verändern
Nur bei einer klaren, getesteten Regel in den Ablauf eingreifen.
Einordnung von Herrlich Consult, gestützt auf die dokumentierten Hook-Ebenen.
Für die Praxis folgt daraus eine einfache Reihenfolge. Zuerst beobachten: Was passiert an der fraglichen Stelle wirklich? Danach hinweisen: Welche Information hilft einer Person oder einem Agenten, besser zu entscheiden? Erst wenn beides präzise beschrieben und getestet ist, sollte ein Mod einen Schritt verändern. Das hält die Wirkung klein genug, um sie bei einem Update nachvollziehen zu können.
vom experiment zur funktion
Zeitlinie: Ankündigung der Claude Mods am 9. September 2026 und Aufnahme in die Release Notes von Claude Code 2.1.287 am 1. Oktober 2026.
- 09.09.2026 · angekündigt
Ankündigung
Anthropic benennt die Erweiterbarkeit über Function Hooks als Claude Mods.
- 01.10.2026 · veröffentlicht
Release 2.1.287
Die Release Notes nennen Claude Mods als neue Möglichkeit, tieferes Verhalten über Plugins anzupassen.
In der Ankündigung vom 9. September beschrieb Anthropic die Idee als tiefere, aber kontrollierbare Erweiterbarkeit. Mit Claude Code 2.1.287 tauchen Claude Mods am 1. Oktober in den Release Notes auf. Die Richtung ist klar: Plugins können näher an die tatsächliche Arbeit rücken, ohne dass jedes Team dafür einen eigenen Agenten-Runner bauen muss.
was das für die praxis bedeutet
Für ein Team sind drei Fragen wichtiger als ein möglichst spektakuläres Plugin. Erstens: Welches konkrete Ereignis soll abgefangen werden? Zweitens: Darf der Mod nur hinweisen, oder darf er einen Schritt verändern? Drittens: Woran erkennt man in einem Test, dass die Erweiterung richtig reagiert und nicht nebenbei den Ablauf ausweitet?
Ein sinnvoller erster Mod ist klein. Er kann vor einem riskanten Tool-Aufruf eine verständliche Prüfung einblenden, einen Review-Handoff mit dem geprüften Stand verknüpfen oder Teamregeln aus einer Datei konsistent verfügbar machen. Was er nicht werden sollte: eine zweite, unübersichtliche Steuerungsschicht, die niemand mehr erklären kann.
warum ein mod einen test braucht
Das offizielle Repository behandelt Mods nicht wie lose Skripte. Die Tests registrieren Ereignisse am Engine-Interface, spielen definierte Antworten ein und prüfen anschließend, was die Erweiterung ausgelöst hat. Diese Denkweise ist für eigene Erweiterungen wertvoll: Nicht nur der glückliche Weg zählt. Ein Test sollte auch zeigen, dass der Mod bei einem fehlenden Kontext, einer abgelehnten Aktion oder einem unbekannten Ereignis nicht still zu viel tut.
Die Mod-Tests im offiziellen Repository arbeiten gegen die Engine. Für Teams beginnt der Nachweis schon vor dem ersten Hook.
- 01
Auslöser
Welches Ereignis startet die Regel?
- 02
Grenze
Was darf der Mod ausdrücklich nicht?
- 03
Test
Welcher Fall belegt die erwartete Wirkung?
- 04
Protokoll
Wo wird die Entscheidung nachvollziehbar?
Quelle: Tests und Typkontrakte im Claude-Code-Mods-Repository, Stand 05.10.2026.
Hinzu kommt ein Realitätscheck: Die Hook-API ist laut Repository Early Access und kann sich zwischen Versionen ändern. Wer einen Mod produktiv nutzt, dokumentiert deshalb die erwartete Claude-Code-Version, prüft den eigenen Testfall nach Updates und hält einen Weg bereit, die Erweiterung schnell abzuschalten. Das ist weniger spektakulär als ein großer Agenten-Entwurf, aber genau so bleibt die Erweiterung beherrschbar.
der kern in drei sätzen
Claude Code Mods sind Plugins mit Function Hooks, nicht nur zusätzliche Prompts. Sie können an definierten Ereignissen im Ablauf reagieren und machen damit Erweiterungen präziser. Der Mehrwert entsteht nur dann, wenn Rechte, Wirkung und Tests des Mods genauso klar sind wie der Rest des Entwicklungsprozesses.
häufige Fragen
Was ist ein Claude Code Mod?
Ein Mod ist ein Claude-Code-Plugin, dessen Verhalten in einem Hooks-Modul liegt. Es registriert sich an Ereignissen der Engine und kann den Ablauf prüfen, ergänzen oder an den nächsten Handler weitergeben.
Sind Mods dasselbe wie Prompts?
Nein. Ein Prompt gibt dem Modell Anweisungen. Ein Mod arbeitet als Plugin am Ablauf von Claude Code und kann zum Beispiel auf Tool-Aufrufe, Oberflächenereignisse oder Agentenaufträge reagieren.
Was sollte ein Team vor einem eigenen Mod klären?
Zuerst den konkreten Auslöser, die erlaubte Wirkung, die Rechte des Plugins und einen Testfall. Ein Mod sollte eine begrenzte Aufgabe lösen und seine Wirkung nachvollziehbar machen.
Sind Claude Code Mods schon eine stabile Schnittstelle?
Nein. Function Hooks sind laut offiziellem Repository Early Access. Teams sollten eigene Mods klein halten, versionieren und nach Updates gezielt testen.
quellen und stand
Stand: 05.10.2026. Technische Grundlage, eingebaute Mods, Testansatz und Early-Access-Hinweis: Claude Code Mods README. Release-Hinweis: Claude Code 2.1.287. Einstellungen für Organisationen und Testhinweise: Claude Code Settings Examples.
