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

Schnellbeispiel

Installieren:

Zwei Wege, benutzerdefinierte Richtlinien zu laden

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 – nicht nach dem Prinzip „erstes Scope gewinnt”)
  • Dateien werden alphabetisch innerhalb jedes Verzeichnisses geladen. Mit dem Präfix 01-, 02- lässt sich die Reihenfolge steuern
  • Nur Dateien, die auf *policies.{js,mjs,ts} passen, werden geladen; andere Dateien werden ignoriert
  • Jede Datei wird unabhängig geladen (fail-open pro Datei)
  • Funktioniert zusammen mit expliziten --custom- und eingebauten Richtlinien
Konventionsrichtlinien sind der einfachste Weg, einen Qualitätsstandard für deine Organisation aufzubauen. Checke .failproofai/policies/ in Git ein, und jedes Teammitglied erhält automatisch dieselben Regeln – kein individuelles Setup nötig. Wenn dein Team neue Fehlerquellen entdeckt, füge eine Richtlinie hinzu und pushe sie. Im Laufe der Zeit entsteht so ein lebendiger 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-Event neu geladen – es gibt kein Caching zwischen Events.

Beide Methoden kombinieren

Konventionsrichtlinien und die explizite --custom-Datei können nebeneinander existieren. Ladereihenfolge:
  1. Explizite customPoliciesPath-Datei (falls konfiguriert)
  2. Projektbezogene Konventionsdateien ({cwd}/.failproofai/policies/, alphabetisch)
  3. Benutzerbezogene Konventionsdateien (~/.failproofai/policies/, alphabetisch)

API

Import

customPolicies.add(hook)

Registriert eine Richtlinie. Kann mehrfach 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 einziges deny bricht die gesamte weitere Auswertung ab. instruct(message) – die Nachricht wird dem Kontext von Claude für den aktuellen Tool-Aufruf hinzugefügt. 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 angibst – ohne Codeänderung. Das funktioniert auch für benutzerdefinierte (custom/), projektbezogene Konventionsrichtlinien (.failproofai-project/) und benutzerbezogene Konventionsrichtlinien (.failproofai-user/). Weitere Details unter Konfiguration → hint.

Informationelle Allow-Nachrichten

allow(message) lässt die Operation durch und sendet gleichzeitig eine informationelle Nachricht an Claude. Die Nachricht wird als additionalContext in der stdout-Antwort des Hook-Handlers übermittelt – derselbe Mechanismus wie bei instruct, aber semantisch anders: Es ist ein Statusupdate, keine Warnung. Anwendungsfälle:
  • Statusbestätigungen: allow("All CI checks passed.") – teilt Claude mit, dass alles grün ist
  • Fail-Open-Erklärungen: allow("GitHub CLI not installed, skipping CI check.") – erklärt Claude, warum eine Prüfung übersprungen wurde, damit es den vollen Kontext hat
  • Mehrere Nachrichten werden gesammelt: Wenn mehrere Richtlinien jeweils allow(message) zurückgeben, werden alle Nachrichten mit Zeilenumbrüchen verbunden und gemeinsam übermittelt

PolicyContext-Felder

SessionMetadata-Felder

Event-Typen


Auswertungsreihenfolge

Richtlinien werden in dieser Reihenfolge ausgewertet:
  1. Eingebaute Richtlinien (in Definitionsreihenfolge)
  2. Explizite benutzerdefinierte Richtlinien aus customPoliciesPath (in .add()-Reihenfolge)
  3. Konventionsrichtlinien aus dem Projekt .failproofai/policies/ (Dateien alphabetisch, .add()-Reihenfolge innerhalb)
  4. Konventionsrichtlinien aus dem Benutzerverzeichnis ~/.failproofai/policies/ (Dateien alphabetisch, .add()-Reihenfolge innerhalb)
Das erste deny bricht die Auswertung aller nachfolgenden Richtlinien ab. Alle instruct-Nachrichten werden gesammelt und gemeinsam übermittelt.

Transitive Imports

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

Event-Typ-Filterung

Mit match.events lässt sich einschränken, wann eine Richtlinie ausgelöst wird:
match vollständig weglassen, um bei jedem Event-Typ 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 Log-Datei:

Vollständiges Beispiel: mehrere Richtlinien


Beispiele

Das Verzeichnis examples/ enthält sofort ausführbare Richtliniendateien:

Explizite Dateibeispiele verwenden

Konventionsbasierte Beispiele verwenden

Kein Installationsbefehl nötig – die Dateien werden beim nächsten Hook-Event automatisch erkannt.