Skip to main content
Benutzerdefinierte Richtlinien ermöglichen es dir, Regeln für beliebiges Agentenverhalten zu schreiben: Projektkonventionen durchsetzen, Drift verhindern, destruktive Operationen kontrollieren, feststeckende Agenten erkennen oder Integrationen mit Slack, Genehmigungsworkflows und mehr umsetzen. Sie verwenden dasselbe Hook-Ereignissystem und die gleichen allow-, deny- und instruct-Entscheidungen wie eingebaute Richtlinien.

Schnellbeispiel

Installieren:

Zwei Wege zum Laden benutzerdefinierter Richtlinien

Option 1: Konventionsbasiert (empfohlen)

Lege *policies.{js,mjs,ts}-Dateien in .failproofai/policies/ ab und sie werden automatisch geladen – keine Flags oder Konfigurationsänderungen erforderlich. Das funktioniert wie Git-Hooks: Datei ablegen, fertig.
So funktioniert es:
  • Sowohl Projekt- als auch Benutzerverzeichnisse werden durchsucht (Vereinigung – kein Gewinnen durch den ersten Scope)
  • Dateien werden innerhalb jedes Verzeichnisses alphabetisch geladen. Mit 01-, 02- etc. lässt sich die Reihenfolge steuern
  • Nur Dateien, die *policies.{js,mjs,ts} entsprechen, werden geladen; andere Dateien werden ignoriert
  • Jede Datei wird unabhängig geladen (fail-open pro Datei)
  • Funktioniert neben explizitem --custom und eingebauten Richtlinien
Konventionsbasierte Richtlinien sind der einfachste Weg, einen Qualitätsstandard für deine Organisation aufzubauen. Checke .failproofai/policies/ ins Git ein und jedes Teammitglied erhält automatisch dieselben Regeln – kein individuelles Setup nötig. Wenn dein Team neue Fehlermuster entdeckt, füge einfach eine Richtlinie hinzu und pushe. Mit der Zeit werden diese zu einem lebendigen Qualitätsstandard, der sich mit jedem Beitrag weiterentwickelt.

Option 2: Expliziter Dateipfad

Der aufgelöste absolute Pfad wird in policies-config.json als customPoliciesPath gespeichert. Die Datei wird bei jedem Hook-Ereignis frisch geladen – es gibt kein Caching zwischen Ereignissen.

Beide Varianten zusammen verwenden

Konventionsbasierte Richtlinien und die explizite --custom-Datei können nebeneinander existieren. Ladereihenfolge:
  1. Explizite customPoliciesPath-Datei (sofern konfiguriert)
  2. Projektkonventionsdateien ({cwd}/.failproofai/policies/, alphabetisch)
  3. Benutzerkonventionsdateien (~/.failproofai/policies/, alphabetisch)

API

Import

customPolicies.add(hook)

Registriert eine Richtlinie. Kann beliebig oft aufgerufen werden, um mehrere Richtlinien in derselben Datei zu definieren.

Entscheidungs-Hilfsfunktionen

deny(message) – die Nachricht erscheint bei Claude mit dem Präfix "Blocked by failproofai:". Ein einzelnes deny schließt alle weiteren Auswertungen kurz. instruct(message) – die Nachricht wird dem Claude-Kontext für den aktuellen Tool-Aufruf angehängt. Alle instruct-Nachrichten werden gesammelt und gemeinsam übermittelt.
Du kannst jeder deny- oder instruct-Nachricht zusätzliche Hinweise hinzufügen, indem du ein hint-Feld in policyParams setzt – ohne Codeänderung. Das funktioniert auch für benutzerdefinierte (custom/), Projektkonventions- (.failproofai-project/) und Benutzerkonventions- (.failproofai-user/) Richtlinien. Siehe Konfiguration → hint für Details.

Informelle allow-Nachrichten

allow(message) erlaubt die Operation und sendet eine informelle Nachricht an Claude zurück. Die Nachricht wird als additionalContext in der stdout-Antwort des Hook-Handlers übermittelt – derselbe Mechanismus wie bei instruct, jedoch semantisch verschieden: Es handelt sich um ein Statusupdate, nicht um eine Warnung. Anwendungsfälle:
  • Statusbestätigungen: allow("All CI checks passed.") – teilt Claude mit, dass alles in Ordnung ist
  • Fail-open-Erklärungen: allow("GitHub CLI not installed, skipping CI check.") – teilt Claude mit, warum eine Prüfung übersprungen wurde, damit der Agent vollständigen Kontext hat
  • Mehrere Nachrichten häufen sich an: Wenn mehrere Richtlinien jeweils allow(message) zurückgeben, werden alle Nachrichten mit Zeilenumbrüchen verbunden und gemeinsam übermittelt

PolicyContext-Felder

SessionMetadata-Felder

Ereignistypen


Auswertungsreihenfolge

Richtlinien werden in dieser Reihenfolge ausgewertet:
  1. Eingebaute Richtlinien (in Definitionsreihenfolge)
  2. Explizite benutzerdefinierte Richtlinien aus customPoliciesPath (in .add()-Reihenfolge)
  3. Konventionsbasierte Richtlinien aus dem Projektverzeichnis .failproofai/policies/ (Dateien alphabetisch, .add()-Reihenfolge innerhalb)
  4. Konventionsbasierte Richtlinien aus dem Benutzerverzeichnis ~/.failproofai/policies/ (Dateien alphabetisch, .add()-Reihenfolge innerhalb)
Das erste deny schließt alle nachfolgenden Richtlinien kurz. Alle instruct-Nachrichten werden gesammelt und gemeinsam übermittelt.

Transitive Importe

Benutzerdefinierte Richtliniendateien können lokale Module über relative Pfade importieren:
Alle von der Einstiegsdatei aus erreichbaren relativen Importe werden aufgelöst. Dies wird durch das Umschreiben von from "failproofai"-Importen auf den tatsächlichen dist-Pfad und das Erstellen temporärer .mjs-Dateien implementiert, um ESM-Kompatibilität sicherzustellen.

Ereignistypfilterung

Verwende match.events, um einzuschränken, wann eine Richtlinie ausgelöst wird:
Lasse match vollständig weg, um bei jedem Ereignistyp auszulösen.

Fehlerbehandlung und Ausfallverhalten

Benutzerdefinierte Richtlinien sind fail-open: Fehler blockieren niemals eingebaute Richtlinien und bringen den Hook-Handler nicht zum Absturz.
Um Fehler in benutzerdefinierten Richtlinien zu debuggen, beobachte die Protokolldatei:

Vollständiges Beispiel: mehrere Richtlinien


Beispiele

Das Verzeichnis examples/ enthält sofort einsatzbereite Richtliniendateien:

Explizite Dateibeispiele verwenden

Konventionsbasierte Beispiele verwenden

Kein Installationsbefehl erforderlich – die Dateien werden beim nächsten Hook-Ereignis automatisch erkannt.