Zum Hauptinhalt springen
Das failproofai Dashboard ist eine lokale Webanwendung zur Überwachung deiner KI-Agent-Sitzungen und zur Verwaltung von Richtlinien. Sieh nach, was deine Agenten in deiner Abwesenheit getan haben.

Dashboard starten

failproofai
Öffnet sich unter http://localhost:8020. Das Dashboard liest direkt aus dem Dateisystem – aus deinen Claude Code Projektordnern und den failproofai Konfigurationsdateien. Es werden keine Daten an einen Remote-Dienst übertragen.

Seiten

Projekte

Listet alle Claude Code, OpenAI Codex, GitHub Copilot CLI (beta), Cursor Agent (beta), OpenCode (beta), Pi (beta) und Gemini CLI (beta) Projekte auf, die auf deinem Rechner gefunden wurden. Claude-Projekte werden aus ~/.claude/projects/ ermittelt (oder dem über CLAUDE_PROJECTS_PATH gesetzten Pfad); Codex-Projekte werden durch Scannen aller Transkripte unter ~/.codex/sessions/<YYYY>/<MM>/<DD>/*.jsonl und Gruppierung nach dem im ersten Datensatz jeder Sitzung gespeicherten cwd ermittelt; Copilot CLI-Projekte werden durch Scannen jeder ~/.copilot/session-state/<sessionId>/workspace.yaml (konfigurierbar über COPILOT_HOME) und Gruppierung nach dem cwd-Feld ermittelt; Cursor Agent-Projekte werden durch Scannen sitzungsspezifischer Metadaten unter ~/.cursor/agent-sessions/<sessionId>/ (konfigurierbar über CURSOR_HOME, mit conversations/ und sessions/ als Fallbacks) nach einem cwd-Skalar in meta.json / session.json / workspace.yaml ermittelt; OpenCode-Projekte werden durch Abfragen der SQLite-Datenbank unter ~/.local/share/opencode/opencode.db via opencode db --format json ermittelt (wir lesen die Tabellen session und project und gruppieren nach project_id); Pi-Projekte werden durch Scannen sitzungsspezifischer JSONL-Transkripte unter ~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<uuid>.jsonl (konfigurierbar über PI_SESSIONS_DIR) und Auslesen des cwd aus dem ersten Datensatz jeder Sitzung ermittelt; Gemini CLI-Projekte werden durch Scannen von ~/.gemini/tmp/<basename>/chats/session-<timestamp>-<uuid-prefix>.jsonl (konfigurierbar über GEMINI_SESSIONS_DIR) und Wiederherstellung des kanonischen cwd aus dem benachbarten .project_root-Textmarker ermittelt. Ein Projekt, das von mehreren CLIs verwendet wurde, erscheint als einzelne Zeile mit allen passenden Badges. Verwende das CLI-Dropdown oberhalb der Tabelle, um nach einer bestimmten Agenten-CLI zu filtern; die URL speichert deine Auswahl als ?cli=claude|codex|copilot|cursor|opencode|pi|gemini. Jedes Projekt zeigt:
  • Projektname (abgeleitet vom Ordnerpfad)
  • Ein CLI-Badge — Claude Code (orange), OpenAI Codex (lila), GitHub Copilot (blau), Cursor Agent (smaragdgrün), OpenCode (bernstein), Pi (pink) und/oder Gemini CLI (himmelblau)
  • Datum der letzten Sitzungsaktivität
Klicke auf ein Projekt, um dessen Sitzungen anzuzeigen.

Sitzungen

Listet alle Sitzungen innerhalb eines Projekts auf. Jede Sitzung zeigt:
  • Sitzungs-ID
  • Start- und End-Zeitstempel
  • Anzahl der Tool-Aufrufe
  • Anzahl der Hook-Aktivitäten (ausgelöste Richtlinien)
Nutze den Datumsbereichsfilter und die Sitzungs-ID-Suche, um die Liste einzugrenzen. Sitzungen sind seitenweise aufgeteilt. Klicke auf eine Sitzung, um den Sitzungs-Viewer zu öffnen.

Sitzungs-Viewer

Der Sitzungs-Viewer beantwortet die entscheidende Frage bei autonomen Agenten: Was hat der Agent getan, und ist er auf Kurs geblieben? Ein CLI-Badge neben der Kopfzeile zeigt an, ob es sich um ein Claude Code-, OpenAI Codex-, GitHub Copilot CLI-, Cursor Agent-, OpenCode-, Pi- oder Gemini CLI-Transkript handelt. Er zeigt eine Zeitleiste aller Ereignisse in einer Sitzung:
  • Nachrichten – Claudes Textantworten und Benutzeranfragen
  • Tool-Aufrufe – Jeder von Claude aufgerufene Tool mit Eingabe und Ausgabe
  • Richtlinienaktivität – Für jeden Tool-Aufruf: welche Richtlinien ausgelöst wurden und welche Entscheidung sie getroffen haben
Die Statistikleiste oben zeigt Sitzungsdauer, Gesamtzahl der Tool-Aufrufe und eine Zusammenfassung der Hook-Entscheidungen (allow / deny / instruct-Anzahl). Klicke auf die Schaltfläche Logs herunterladen, um die Sitzung zu exportieren. Bei Claude Code-, Codex-, Copilot-, Cursor-, Pi- und Gemini-Sitzungen erhältst du das originale JSONL-Transkript vom Datenträger Byte für Byte; bei OpenCode (dessen Sitzungen in SQLite statt auf der Festplatte gespeichert sind) erhältst du ein JSON-Dokument, das die zugrundeliegenden Tabellen session / messages / parts widerspiegelt.

Audit

Ein persönlichkeitsbasierter Bericht darüber, wie sich dein Agent tatsächlich über vergangene Sitzungen hinweg verhalten hat. Führt denselben Scan wie die failproofai audit-CLI durch, stellt ihn aber als sechsteiliges Dashboard dar:
  1. Identität — klassifiziert deinen Agenten in einen von 8 Archetypen (the optimist, the cowboy, the explorer, the goldfish, the paranoid architect, the precision builder, the hammer, the ghost) basierend darauf, welche Detektoren und Richtlinien ausgelöst wurden und wie stark. Zeigt ein 8×8-Pixel-Sigil, den Archetyp-Slogan, die Framing-Aspekte „häufig bei” / „primäres Risiko” und den abschließenden Einzeiler.
  2. Deinen Agenten vorstellen — erfasst die Identitätskarte als 1200×630 PNG, das zum Posten auf X / LinkedIn geeignet ist (klicke auf make poster).
  3. Stärken — grün markierte Verhaltensweisen, die dein Agent bereits richtig macht, abgeleitet aus den aktuellen Audit-Daten (saubere Tool-Aufruf-Rate, durchschnittliche Sitzungslänge, keine Credential-Lecks, keine Retry-Stürme usw.).
  4. Bewertung + Bestenliste — Punktzahl von 0–100 mit Buchstabennote (S/A/B/C/D/F), ein Verteilungshistogramm mit deiner Position in der Kohorte, Prosatext („a B starts at 71. you’re 13 points away.”) und eine Bestenliste mit deiner hervorgehobenen Zeile.
  5. Befunde — nach Auswirkung gerankte Befundkarten. Jede Karte zeigt, was passiert ist, was es kostet, eine Beweisauswahl mit echten aufgezeichneten Befehlen und die failproofai-Richtlinie, die dasselbe Muster erkennen würde ($ failproofai policy add <slug>, zum Kopieren klicken).
  6. Empfohlene Richtlinien + Rückkehr-Schleife — ein Raster aller nicht aktivierten eingebauten Richtlinien, die eine Lücke schließen würden, mit einem projizierten Punktzahl-Hinweis sowie einem „Re-Audit in 7 Tagen”-CTA.
Angetrieben von der failproofai audit-Laufzeitumgebung — siehe Audit CLI für die zugrundeliegende Scan-Engine, unterstützte Flags und Transkript-Cache-Invarianten. Das Dashboard speichert das neueste Ergebnis unter ~/.failproofai/audit-dashboard.json (Modus 0600, ein Slot, neue Läufe überschreiben), sodass Folgebesuche sofort laden; sowohl der Transkript-Cache als auch der Gesamtergebnis-Cache werden beim Lesen verworfen, sobald sie älter als 7 Tage sind, damit das Dashboard niemals still und leise ein wochealtes Ergebnis ausliefert — nach Ablauf der TTL fällt /audit auf den leeren Zustand zurück und fordert einen neuen Lauf an. Ein Klick auf [ re-audit now ] im unteren Bereich des Berichts sendet einen POST an /api/audit/run mit noCache: true — ein Re-Audit umgeht den Transkript-Cache und scannt jedes Transkript von Grund auf neu, anstatt still das gecachte Ergebnis zurückzugeben — und das Dashboard fragt /api/audit/status mit 1Hz ab, bis der Lauf abgeschlossen ist; ein pinker Fortschrittsstreifen bleibt während des Laufs mit einem Laufzeittimer oben im Viewport angeheftet, und das frische Ergebnis wird bei Erfolg direkt eingefügt (kein vollständiges Neuladen der Seite; ein fehlgeschlagenes Re-Audit lässt den vorherigen Bericht intakt). Bei einem Fehler wird der Streifen rot mit Text, der auf den RerunError.kind abgestimmt ist (timeout / network / post_failed). Leerzustand (kein Cache oder abgelaufen) und Null-Sitzungs-Zustand (Cache vorhanden, aber der Scan hat keine Transkripte gefunden) werden separat angezeigt.

Richtlinien

Eine zweiseitige Seite zur Verwaltung von Richtlinien und zur Überprüfung von Aktivitäten.
  • Wähle in einem einzigen Panel aus, welche Agenten-CLIs failproofai schützt — Claude Code, OpenAI Codex, GitHub Copilot, Cursor Agent, OpenCode, Pi und Gemini CLI haben jeweils eine Zeile mit Installationsstatus (Active / Detected / Inactive), dem Einstellungspfad für den Benutzerbereich und einem markenspezifischen Akzent. Aktiviere oder deaktiviere die gewünschten CLIs und klicke auf Apply changes, um die Änderungen in einem Schritt zu installieren/deinstallieren. CLIs, deren Binary im PATH erkannt wird, sind vorab aktiviert.
  • Aktiviere oder deaktiviere einzelne Richtlinien mit einem Klick (schreibt in ~/.failproofai/policies-config.json — geteilt über alle installierten CLIs)
  • Erweitere eine Richtlinie, um ihre Parameter zu konfigurieren (für Richtlinien, die policyParams unterstützen)
  • Lege einen benutzerdefinierten Richtliniendateipfad fest

Automatische Aktualisierung

Das Dashboard verfügt über einen Auto-Refresh-Schalter in der oberen Navigation. Wenn aktiviert, wird die aktuelle Seite periodisch aktualisiert, um neue Sitzungen und Richtlinienaktivitäten anzuzeigen, sobald sie erscheinen. Unverzichtbar für die Überwachung lang laufender autonomer Agent-Sitzungen.

Seiten deaktivieren

Wenn du nur bestimmte Teile des Dashboards benötigst, setze FAILPROOFAI_DISABLE_PAGES auf eine kommagetrennte Liste von Seitennamen:
FAILPROOFAI_DISABLE_PAGES=policies failproofai
Gültige Werte: policies, projects, audit.

Projektpfad konfigurieren

Standardmäßig liest das Dashboard aus dem Standard-Claude Code Projektverzeichnis. Überschreibe es für benutzerdefinierte Setups:
CLAUDE_PROJECTS_PATH=/custom/path/to/projects failproofai

Zugriff von einem Nicht-localhost-Host

Wenn du das Dashboard im Entwicklungsmodus (npm run dev) betreibst und von einem anderen Hostnamen als localhost darauf zugreifst – zum Beispiel einer benutzerdefinierten Domain, einer Remote-IP oder einer getunnelten URL – siehst du möglicherweise eine Warnung wie:
⚠ Blocked cross-origin request to Next.js dev resource /_next/webpack-hmr from "dashboard.example.com".
Das ist Next.js, das den ursprungsübergreifenden Zugriff auf seinen HMR-Websocket (Hot Module Reload) blockiert, welcher ein rein entwicklungsspezifisches Feature ist. Um deinen Host zuzulassen, verwende das Flag --allowed-origins:
npm run dev -- --allowed-origins dashboard.example.com
Für mehrere Hosts oder IPs übergib eine kommagetrennte Liste:
npm run dev -- --allowed-origins dashboard.example.com,192.168.1.5
Du kannst alternativ auch die Umgebungsvariable FAILPROOFAI_ALLOWED_DEV_ORIGINS setzen:
FAILPROOFAI_ALLOWED_DEV_ORIGINS=dashboard.example.com npm run dev
Dies gilt nur für den Entwicklungsmodus. Beim Ausführen von failproofai (Produktionsmodus) gibt es keinen HMR-Websocket und kein ursprungsübergreifendes Entwicklungsressourcen-Problem.