Claude · 10 Min.
Claude Code Hooks: Die Kontrollschicht, die AI Coding teamfaehig macht
Claude Code Hooks sind keine netten Automationen. Richtig gebaut werden sie zur Governance-Schicht fuer agentische Softwarearbeit.
SYSTEMS Grafik zu Claude Code Hooks: Explore -> Plan -> Verify. Fokus: Wie Claude Code Hooks Teams helfen, Agentic Coding sicherer, reproduzierbarer und enterprise-faehig zu machen.
Kurzfassung
Hooks sind die Governance-Schicht zwischen Agentenaktion und Projektrisiko. Entscheidend sind Lifecycle-Punkte wie `PreToolUse`, `PostToolUse`, `SubagentStop`, `PreCompact` und `SessionEnd`. Teams sollten Hooks nicht fuer Kosmetik einsetzen, sondern fuer Sicherheitsgrenzen, Test-Evidenz und saubere Uebergaben.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Warum Hooks wichtiger sind als noch bessere Prompts Ein Prompt kann eine Regel erwaehnen. Ein Hook kann sie an der richtigen Stelle erzwingen. Genau das macht den Unterschied zwischen "AI Coding ausprobieren" und einem Workflow, den ein Team jeden Tag nutzen kann.
Claude Code Hooks greifen an konkreten Punkten im Arbeitszyklus: vor Tool-Aufrufen, nach Tool-Ergebnissen, beim Start und Ende von Subagents, beim Kompaktieren des Kontextes, beim Session-Ende oder bei Konfigurationsaenderungen. Dadurch werden Regeln nicht nur erinnert, sondern in die Ausfuehrung eingebaut.
Das ist fuer Unternehmen entscheidend. Agenten koennen Dateien schreiben, Shell-Befehle starten, MCP -Tools nutzen und Subagents delegieren. Ohne Kontrollpunkte entsteht Geschwindigkeit, aber keine Verlaesslichkeit.
Der falsche Einsatz: Hooks als Benachrichtigungs-Spielzeug Viele Teams beginnen mit Hooks fuer kleine Komfortaufgaben: Sound abspielen, Slack-Nachricht schicken, Formatierung starten. Das ist nicht falsch, aber es ist nicht der grosse Hebel.
Der grosse Hebel liegt dort, wo ein Agent echten Schaden oder stille Qualitaetsverluste erzeugen kann:
Ein guter Hook beantwortet nicht "Was waere nett?", sondern "Welche Regel darf im Arbeitsfluss nie vergessen werden?"
`PreToolUse`: riskante Befehle, fremde Pfade, Secrets, Produktionszugriffe oder falsche Projektgrenzen blocken. `PostToolUse`: nach Datei-Aenderungen passende Checks anstossen oder Evidenz sammeln. `PostToolBatch`: nach parallelen Tool-Aufrufen pruefen, ob ein Agent wieder konsistent weiterarbeiten kann. `SubagentStart` und `SubagentStop`: Delegation sichtbar machen und Ergebnisse gegen den Auftrag pruefen. `PreCompact`: vor Kontextkomprimierung Handoff-Notizen, offene Risiken und naechste Schritte sichern. `SessionEnd`: Abschlussprotokoll, Tests und offene Punkte festhalten. Command, HTTP, MCP, Prompt und Agent Hooks richtig einordnen Claude Code Hooks sind nicht mehr nur Shell-Skripte. Die aktuelle Doku unterscheidet mehrere Hook-Handler: Command Hooks, HTTP Hooks, MCP Tool Hooks, Prompt Hooks und Agent Hooks.
Das ist wichtig fuer Architekturentscheidungen:
SYSTEMS wuerde in einem Team nicht alles in einen grossen Hook packen. Besser ist eine kleine Hook-Topologie: schnelle lokale Gates zuerst, teurere Reviews nur bei riskanten Dateien oder vor dem finalen Report.
Command Hooks sind gut fuer lokale Checks: Git-Status, Lint, Typecheck, verbotene Befehle, Dateipfade. HTTP Hooks passen fuer zentrale Policy-Systeme, Audit-Logs oder Security-Services, brauchen aber URL-Allowlists. MCP Tool Hooks sind relevant, wenn Agenten ueber Connectoren mit externen Systemen sprechen. Prompt Hooks eignen sich fuer Bewertungslogik, wenn ein statisches Skript zu wenig Kontext hat. Agent Hooks koennen komplexere Reviews oder Done-Gates ausfuehren. Enterprise-Governance: Managed Scope statt Jeder-baut-sein-Setup Der wichtigste Punkt fuer groessere Teams ist nicht der Hook selbst, sondern wer ihn kontrolliert. Claude Code kennt User-, Project-, Local- und Managed-Scopes. Managed Settings haben die hoechste Prioritaet und koennen nicht durch lokale Projektkonfiguration ueberschrieben werden.
Fuer Teams bedeutet das:
Besonders relevant sind Einstellungen wie `allowManagedHooksOnly`, `allowedHttpHookUrls`, `allowedMcpServers` und `allowManagedMcpServersOnly`. Damit kann ein Unternehmen definieren, welche Hook-Quellen, HTTP-Ziele und MCP-Server ueberhaupt erlaubt sind.
Das ist der Unterschied zwischen "Wir nutzen Claude Code" und "Wir betreiben Claude Code als kontrollierte Engineering-Infrastruktur".
Projekt-Hooks sind gut fuer gemeinsame Repo-Konventionen. Lokale Hooks sind gut fuer persoenliche Experimente. Managed Hooks sind gut fuer Unternehmensregeln, Compliance und Security. Ein gutes Hook-System sieht aus wie ein Delivery-Gate Ein praxistaugliches Setup besteht aus Schichten.
Erste Schicht: Preflight. Beim Session-Start werden Projektregeln, Branch, Dirty-State, Runtime-Owner und verbotene Bereiche sichtbar gemacht.
Zweite Schicht: Tool-Gates. Vor Schreibaktionen werden riskante Befehle, falsche Pfade, Secrets und Produktionszugriffe abgefangen.
Dritte Schicht: Change-Gates. Nach Datei-Aenderungen werden passende Checks vorgeschlagen oder gestartet: Typecheck fuer TypeScript, Tests fuer Backend-Module, SEO-Audit fuer Blog-Artefakte, RLS-Pruefung fuer Supabase.
Vierte Schicht: Delegation-Gates. Wenn Subagents laufen, muss klar sein, welcher Agent welche Dateien besitzt, welche Tests er liefern muss und wann Integration beginnt.
Fuenfte Schicht: Done-Gate. Vor dem finalen Report wird geprueft: Build gruen? Audit gruen? Offene Risiken dokumentiert? Fremde Aenderungen unangetastet? Handoff geschrieben?
Was Teams nicht automatisieren sollten Nicht jede Entscheidung gehoert in einen Hook. Wenn ein Hook staendig blockiert, stumpft das Team ab. Wenn er zu langsam ist, umgehen ihn Menschen. Wenn er zu breit ist, verursacht er Fehlalarme.
Gute Hooks sind klein, schnell und eindeutig. Sie blockieren harte Risiken und sammeln Evidenz fuer den Rest.
Ein schlechter Hook sagt: "Vielleicht koennte das ein Problem sein." Ein guter Hook sagt: "Diese konkrete Aktion verletzt diese konkrete Regel."
Der SYSTEMS-Blick Claude Code Hooks sind fuer uns kein Feature, sondern ein Betriebssystem-Baustein fuer AI Engineering. Sie machen Agenten nicht perfekt. Sie machen ihre Arbeit beobachtbar, begrenzbar und wiederholbar.
Unternehmen, die AI Coding ernst nehmen, sollten nicht nur fragen: "Welches Modell schreibt den besten Code?" Die bessere Frage ist: "Welche Architektur sorgt dafuer, dass Agenten im richtigen Rahmen arbeiten?"
Wenn diese Schicht steht, wird Claude Code nicht nur schneller. Es wird teamfaehig.
