Skip to main content

Hooks

Hooks bieten ein erweiterbares, ereignisgesteuertes System zur Automatisierung von Aktionen als Reaktion auf Agent-Befehle und -Ereignisse. Hooks werden automatisch aus Verzeichnissen erkannt und können über CLI-Befehle verwaltet werden, ähnlich wie Skills in OpenClaw funktionieren.

Orientierung

Hooks sind kleine Skripte, die ausgeführt werden, wenn etwas passiert. Es gibt zwei Arten:
  • Hooks (diese Seite): werden im Gateway ausgeführt, wenn Agent-Ereignisse ausgelöst werden, z. B. /new, /reset, /stop oder Lifecycle-Ereignisse.
  • Webhooks: externe HTTP-Webhooks, mit denen andere Systeme Arbeit in OpenClaw auslösen können. Siehe Webhook Hooks oder verwenden Sie openclaw webhooks für Gmail-Hilfsbefehle.
Hooks können auch in Plugins gebündelt werden; siehe Plugins. Häufige Anwendungsfälle:
  • Einen Memory-Snapshot speichern, wenn Sie eine Sitzung zurücksetzen
  • Einen Audit-Trail von Befehlen zur Fehlerbehebung oder Compliance führen
  • Folgeautomatisierungen auslösen, wenn eine Sitzung beginnt oder endet
  • Dateien in den Agent-Arbeitsbereich schreiben oder externe APIs aufrufen, wenn Ereignisse ausgelöst werden
Wenn Sie eine kleine TypeScript-Funktion schreiben können, können Sie auch einen Hook schreiben. Hooks werden automatisch erkannt, und Sie aktivieren oder deaktivieren sie über die CLI.

Überblick

Das Hook-System ermöglicht Ihnen:
  • Sitzungs-Kontext in den Speicher zu sichern, wenn /new ausgeführt wird
  • Alle Befehle für Audit-Zwecke zu protokollieren
  • Benutzerdefinierte Automatisierungen bei Agent-Lifecycle-Ereignissen auszulösen
  • Das Verhalten von OpenClaw zu erweitern, ohne den Core-Code zu verändern

Erste Schritte

Gebündelte Hooks

OpenClaw wird mit vier gebündelten Hooks ausgeliefert, die automatisch erkannt werden:
  • 💾 session-memory: Speichert den Sitzungs-Kontext in Ihrem Agent-Arbeitsbereich (Standard ~/.openclaw/workspace/memory/), wenn Sie /new ausführen
  • 😈 soul-evil: Tauscht injizierten SOUL.md-Inhalt während eines Purge-Fensters oder mit zufälliger Wahrscheinlichkeit gegen SOUL_EVIL.md aus
  • 📝 command-logger: Protokolliert alle Befehlsereignisse in ~/.openclaw/logs/commands.log
  • 🚀 boot-md: Führt BOOT.md aus, wenn das Gateway startet (erfordert aktivierte interne Hooks)
Verfügbare Hooks auflisten:
Einen Hook aktivieren:
Hook-Status prüfen:
Detaillierte Informationen abrufen:

Onboarding

Während des Onboardings (openclaw onboard) werden Sie aufgefordert, empfohlene Hooks zu aktivieren. Der Assistent erkennt automatisch geeignete Hooks und stellt sie zur Auswahl.

Hook-Erkennung

Hooks werden automatisch aus drei Verzeichnissen erkannt (in der Reihenfolge der Priorität):
  1. Workspace-Hooks: <workspace>/hooks/ (pro Agent, höchste Priorität)
  2. Verwaltete Hooks: ~/.openclaw/hooks/ (benutzerinstalliert, gemeinsam über Workspaces hinweg)
  3. Gebündelte Hooks: <openclaw>/dist/hooks/bundled/ (mit OpenClaw ausgeliefert)
Verwaltete Hook-Verzeichnisse können entweder ein einzelner Hook oder ein Hook-Pack (Paketverzeichnis) sein. Jeder Hook ist ein Verzeichnis mit folgendem Inhalt:

Hook-Packs (npm/Archive)

Hook-Packs sind standardmäßige npm-Pakete, die einen oder mehrere Hooks über openclaw.hooks in package.json exportieren. Installieren Sie sie mit:
Git/URL-/Dateispezifikationen werden abgelehnt. Sicherheitshinweis: openclaw hooks install installiert Abhängigkeiten mit npm install --ignore-scripts (keine Lifecycle-Skripte). Beispiel package.json:
Jeder Eintrag verweist auf ein Hook-Verzeichnis, das HOOK.md und handler.ts (oder index.ts) enthält. Hook-Packs können Abhängigkeiten mitbringen; diese werden unter ~/.openclaw/hooks/<id> installiert. Halte die Abhängigkeitsbäume von Hook-Paketen “pure JS/TS” und vermeide Pakete, die auf postinstall-Builds angewiesen sind. Hinweis: module muss ein workspace-relativer Pfad sein.

Hook-Struktur

HOOK.md-Format

Die Datei HOOK.md enthält Metadaten im YAML-Frontmatter sowie Markdown-Dokumentation:

Metadatenfelder

Das Objekt metadata.openclaw unterstützt:
  • emoji: Anzeige-Emoji für die CLI (z. B. "💾")
  • events: Array von Ereignissen, auf die gehört wird (z. B. ["command:new", "command:reset"])
  • export: Zu verwendender benannter Export (Standard: "default")
  • homepage: Dokumentations-URL
  • requires: Optionale Anforderungen
    • bins: Erforderliche Binaries im PATH (z. B. ["git", "node"])
    • anyBins: Mindestens eines dieser Binaries muss vorhanden sein
    • env: Erforderliche Umgebungsvariablen
    • soul-evil
    • os: Erforderliche Plattformen (z. B. ["darwin", "linux"])
  • always: Eignungsprüfungen umgehen (boolean)
  • install: Installationsmethoden (für gebündelte Hooks: [{"id":"bundled","kind":"bundled"}])

Handler-Implementierung

Die Datei handler.ts exportiert eine Funktion HookHandler:

Ereigniskontext

Jedes Ereignis enthält:

Ereignistypen

Befehlsereignisse

Ausgelöst, wenn Agent-Befehle ausgeführt werden:
  • command: Alle Befehlsereignisse (allgemeiner Listener)
  • command:new: Wenn der Befehl /new ausgeführt wird
  • command:reset: Wenn der Befehl /reset ausgeführt wird
  • command:stop: Wenn der Befehl /stop ausgeführt wird

Agent-Ereignisse

  • agent:bootstrap: Bevor Workspace-Bootstrap-Dateien injiziert werden (Hooks dürfen context.bootstrapFiles verändern)

Gateway-Ereignisse

Ausgelöst, wenn das Gateway startet:
  • gateway:startup: Nachdem Kanäle gestartet sind und Hooks geladen wurden

Tool-Result-Hooks (Plugin-API)

Diese Hooks sind keine Event-Stream-Listener; sie ermöglichen es Plugins, Tool-Ergebnisse synchron anzupassen, bevor OpenClaw sie persistiert.
  • tool_result_persist: Transformiert Tool-Ergebnisse, bevor sie in das Sitzungsprotokoll geschrieben werden. Muss synchron sein; geben Sie die aktualisierte Tool-Ergebnis-Payload zurück oder undefined, um sie unverändert zu lassen. Siehe Agent Loop.

Zukünftige Ereignisse

Geplante Ereignistypen:
  • session:start: Wenn eine neue Sitzung beginnt
  • session:end: Wenn eine Sitzung endet
  • agent:error: Wenn ein Agent auf einen Fehler stößt
  • message:sent: Wenn eine Nachricht gesendet wird
  • message:received: Wenn eine Nachricht empfangen wird

Eigene Hooks erstellen

1. Ort wählen

  • Workspace-Hooks (<workspace>/hooks/): Pro Agent, höchste Priorität
  • Verwaltete Hooks (~/.openclaw/hooks/): Gemeinsam über Workspaces hinweg

2. Verzeichnisstruktur erstellen

3. HOOK.md erstellen

4. handler.ts erstellen

5. Aktivieren und testen

Konfiguration

Neues Konfigurationsformat (empfohlen)

Pro-Hook-Konfiguration

Hooks können eine benutzerdefinierte Konfiguration haben:

Zusätzliche Verzeichnisse

Hooks aus zusätzlichen Verzeichnissen laden:

Legacy-Konfigurationsformat (weiterhin unterstützt)

Das alte Konfigurationsformat funktioniert aus Gründen der Abwärtskompatibilität weiterhin:
Absolute Pfade und Traversal außerhalb des Workspace werden abgelehnt. bootstrap-extra-files Migration: Verwenden Sie für neue Hooks das neue, erkennungsgestützte System. Legacy-Handler werden nach den verzeichnisbasierten Hooks geladen.

CLI-Befehle

Hooks auflisten

Hook-Informationen

Eignung prüfen

Aktivieren/Deaktivieren

Referenz der gebündelten Hooks

session-memory

Speichert den Sitzungs-Kontext im Speicher, wenn Sie /new ausführen. Ereignisse: command:new Anforderungen: workspace.dir muss konfiguriert sein Ausgabe: <workspace>/memory/YYYY-MM-DD-slug.md (Standard: ~/.openclaw/workspace) Was es tut:
  1. Verwendet den Vor-Reset-Sitzungseintrag, um das korrekte Transkript zu finden
  2. Extrahiert die letzten 15 Zeilen der Konversation
  3. Verwendet ein LLM, um einen beschreibenden Dateinamen-Slug zu generieren
  4. Speichert Sitzungsmetadaten in einer datierten Memory-Datei
Beispielausgabe:
Beispiele für Dateinamen:
  • 2026-01-16-vendor-pitch.md
  • 2026-01-16-api-design.md
  • 2026-01-16-1430.md (Fallback-Zeitstempel, falls die Slug-Generierung fehlschlägt)
Aktivieren:

Pfade werden relativ zum Workspace aufgelöst.

Tauscht injizierten SOUL.md-Inhalt während eines Purge-Fensters oder mit zufälliger Wahrscheinlichkeit gegen SOUL_EVIL.md aus. Ereignisse: agent:bootstrap Docs: SOUL Evil Hook Ausgabe: Es werden keine Dateien geschrieben; die Tauschaktionen erfolgen ausschließlich im Speicher. Konfiguration:
Einführung
  • Dateien müssen innerhalb des Workspace bleiben (realpath-geprüft).
  • Es werden nur erkannte Bootstrap-Basenamen geladen.
  • Die Subagent-Allowlist bleibt erhalten (nur AGENTS.md und TOOLS.md).
  • openclaw hooks enable bootstrap-extra-files
Aktivieren:

command-logger

Protokolliert alle Befehlsereignisse in eine zentrale Audit-Datei. Ereignisse: command Anforderungen: Keine Ausgabe: ~/.openclaw/logs/commands.log Was es tut:
  1. Erfasst Ereignisdetails (Befehlsaktion, Zeitstempel, Sitzungs-Schlüssel, Absender-ID, Quelle)
  2. Hängt sie im JSONL-Format an die Logdatei an
  3. Läuft unauffällig im Hintergrund
Beispiel-Logeinträge:
Logs anzeigen:
Aktivieren:

boot-md

Führt BOOT.md aus, wenn das Gateway startet (nachdem die Kanäle gestartet sind). Interne Hooks müssen aktiviert sein, damit dies ausgeführt wird. Ereignisse: gateway:startup Anforderungen: workspace.dir muss konfiguriert sein Was es tut:
  1. Liest BOOT.md aus Ihrem Workspace
  2. Führt die Anweisungen über den Agent-Runner aus
  3. Sendet angeforderte ausgehende Nachrichten über das Nachrichten-Werkzeug
Aktivieren:

Best Practices

Handler schnell halten

Hooks laufen während der Befehlsverarbeitung. Halten Sie sie leichtgewichtig:

Fehler robust behandeln

Umschließen Sie riskante Operationen immer:

Ereignisse früh filtern

Beenden Sie frühzeitig, wenn das Ereignis nicht relevant ist:

Spezifische Ereignisschlüssel verwenden

Geben Sie in den Metadaten nach Möglichkeit exakte Ereignisse an:
Stattdessen:

Debugging

Hook-Logging aktivieren

Das Gateway protokolliert das Laden von Hooks beim Start:

Erkennung prüfen

Alle erkannten Hooks auflisten:

Registrierung prüfen

Protokollieren Sie in Ihrem Handler, wann er aufgerufen wird:

Eignung verifizieren

Prüfen Sie, warum ein Hook nicht geeignet ist:
Achten Sie in der Ausgabe auf fehlende Anforderungen.

Testen

Gateway-Logs

Überwachen Sie die Gateway-Logs, um die Ausführung von Hooks zu sehen:

Hooks direkt testen

Testen Sie Ihre Handler isoliert:

Architektur

Kernkomponenten

  • src/hooks/types.ts: Typdefinitionen
  • src/hooks/workspace.ts: Verzeichnisscans und Laden
  • src/hooks/frontmatter.ts: Parsing der HOOK.md-Metadaten
  • src/hooks/config.ts: Eignungsprüfung
  • src/hooks/hooks-status.ts: Statusberichterstattung
  • src/hooks/loader.ts: Dynamischer Modul-Loader
  • src/cli/hooks-cli.ts: CLI-Befehle
  • src/gateway/server-startup.ts: Lädt Hooks beim Gateway-Start
  • src/auto-reply/reply/commands-core.ts: Löst Befehlsereignisse aus

Erkennungsfluss

Ereignisfluss

Fehlerbehebung

Hook nicht erkannt

  1. Verzeichnisstruktur prüfen:
  2. HOOK.md-Format verifizieren:
  3. Alle erkannten Hooks auflisten:

Hook wird nicht ausgeführt

Anforderungen prüfen:
Achten Sie auf fehlende:
  • Binaries (PATH prüfen)
  • Umgebungsvariablen
  • Konfigurationswerte
  • OS-Kompatibilität

Hook nicht geeignet

  1. Prüfen, ob der Hook aktiviert ist:
  2. Starten Sie Ihren Gateway-Prozess neu, damit Hooks neu geladen werden.
  3. Prüfen Sie die Gateway-Logs auf Fehler:

Handler-Fehler

Auf TypeScript-/Import-Fehler prüfen:

Migrationsleitfaden

Von Legacy-Konfiguration zu Erkennung

Vorher:
Nachher:
  1. Hook-Verzeichnis erstellen:
  2. HOOK.md erstellen:
  3. Konfiguration aktualisieren:
  4. Verifizieren und Ihren Gateway-Prozess neu starten:
Vorteile der Migration:
  • Automatische Erkennung
  • CLI-Verwaltung
  • Berechtigungsprüfung
  • Bessere Dokumentation
  • Konsistente Struktur

Siehe auch