Skip to main content
Das failproofai Dashboard ist eine lokale Webanwendung zur Überwachung Ihrer KI-Agent-Sitzungen und zur Verwaltung von Richtlinien. Sehen Sie nach, was Ihre Agenten in Ihrer Abwesenheit getan haben.

​
Dashboard starten

Öffnet sich unter http://localhost:8020. Das Dashboard liest lokale Projekt-, Sitzungs- und failproofai-Konfigurationsdaten direkt vom Dateisystem. Optionale authentifizierte Funktionen, wie Audit-Erinnerungen und Einladungen, übermitteln die für diese Anfragen benötigten Informationen (einschließlich E-Mail-Adressen) an Remote-APIs.

​
Seiten

​
Projekte

Listet alle auf Ihrem Rechner gefundenen Claude Code-, OpenAI Codex-, GitHub Copilot CLI- (Beta), Cursor Agent- (Beta), OpenCode- (Beta), Pi- (Beta), Hermes-, OpenClaw-, Factory Droid-, Devin-, Antigravity- und Goose-Projekte auf. Claude-Projekte werden aus ~/.claude/projects/ (oder dem über CLAUDE_PROJECTS_PATH gesetzten Pfad) ermittelt; 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 gefunden; 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 von sitzungsspezifischen 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 gefunden; OpenCode-Projekte werden durch Abfrage seiner SQLite-Datenbank unter ~/.local/share/opencode/opencode.db via opencode db --format json ermittelt (es werden die Tabellen session und project gelesen und nach project_id gruppiert); Pi-Projekte werden durch Scannen von sitzungsspezifischen JSONL-Transkripten unter ~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<uuid>.jsonl (konfigurierbar über PI_SESSIONS_DIR) und Auslesen des cwd aus dem ersten Datensatz jeder Sitzung gefunden; Hermes Gateway-Sitzungen werden direkt aus dem SQLite-Speicher unter ~/.hermes/state.db (konfigurierbar über HERMES_DB_PATH) gelesen und nach source (Slack/Telegram/cli/cron — Gateway-Sitzungen haben kein cwd) in hermes-<source>-Projekte gruppiert; OpenClaw Gateway-Sitzungen werden aus ~/.openclaw/agents/<agentId>/sessions/*.jsonl gelesen und in openclaw-<agentId>-Projekte gruppiert (ebenfalls ohne cwd); Factory Droid-Projekte werden aus den JSONL-Transkripten unter ~/.factory/sessions/<encoded-cwd>/*.jsonl ermittelt und nach cwd gruppiert; Devin-Projekte aus seiner SQLite-Datenbank unter ~/.local/share/devin/cli/sessions.db (gruppiert nach dem working_directory jeder Sitzung); Antigravity-Projekte aus den JSONL-Transkripten unter ~/.gemini/antigravity-cli/brain/<conversationId>/…/transcript_full.jsonl und nach cwd gruppiert; und Goose-Projekte aus seiner SQLite-Datenbank unter ~/.local/share/goose/sessions/sessions.db (gruppiert nach dem working_dir jeder Sitzung). Ein Projekt, das von mehreren CLIs verwendet wurde, wird als einzelne Zeile mit allen passenden Badges dargestellt. Verwenden Sie das CLI-Dropdown über der Tabelle, um nach einer bestimmten Agent-CLI zu filtern; die URL behält Ihre Auswahl als ?cli=claude|codex|copilot|cursor|opencode|pi|hermes|openclaw|factory|devin|antigravity|goose bei. 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 Hermes (indigo)
  • Datum der letzten Sitzungsaktivität
Klicken Sie auf ein Projekt, um seine Sitzungen anzuzeigen.

​
Sitzungen

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

​
Sitzungs-Viewer

Der Sitzungs-Viewer beantwortet die zentrale Frage bei autonomen Agenten: Was hat der Agent getan, und ist er auf Kurs geblieben? Ein CLI-Badge neben dem Header gibt an, ob es sich um ein Claude Code-, OpenAI Codex-, GitHub Copilot CLI-, Cursor Agent-, OpenCode-, Pi-, Hermes-, OpenClaw-, Factory Droid-, Devin-, Antigravity- oder Goose-Transkript handelt. Er zeigt eine Zeitleiste aller Ereignisse in einer Sitzung:
  • Nachrichten - Claudes Textantworten und Benutzeranfragen
  • Tool-Aufrufe - Jedes von Claude aufgerufene Tool, mit Ein- und Ausgabe
  • Richtlinienaktivität - Für jeden Tool-Aufruf: welche Richtlinien ausgelöst wurden und welche Entscheidung sie zurückgegeben haben
Die Statistikleiste oben zeigt Sitzungsdauer, Gesamtanzahl der Tool-Aufrufe und eine Zusammenfassung der Hook-Entscheidungen (Anzahl von allow / deny / instruct). Klicken Sie auf die Schaltfläche Logs herunterladen, um die Sitzung zu exportieren. Bei Claude Code-, Codex-, Copilot-, Cursor- und Pi-Sitzungen erhalten Sie das originale JSONL-Transkript auf dem Datenträger Byte für Byte; bei OpenCode (dessen Sitzungen in SQLite, nicht auf dem Datenträger gespeichert sind) erhalten Sie ein JSON-Dokument, das die zugrundeliegenden Tabellen session / messages / parts widerspiegelt.

​
Audit

Ein charaktergetriebener Bericht darüber, wie sich Ihr Agent tatsächlich über vergangene Sitzungen hinweg verhalten hat. Führt denselben Scan wie die failproofai audit-CLI aus, stellt ihn aber als einseitiges, teilbares Poster + vier unterhalb des sichtbaren Bereichs liegende Abschnitte dar:
  1. Poster — füllt den ersten Viewport. Eigenständiger PNG-Erfassungsbereich mit dem failproof_ai-Wortzeichen + Audit-Label · Archetyp-Index (№ NN of 08) + Audit-Datum · numerischer Score (0–100) + Perzentil-Rang-Pill (top 15%) · der Archetyp-Name (einer von the optimist, the cowboy, the explorer, the goldfish, the paranoid architect, the precision builder, the hammer, the ghost) + 3-Keyword-Streifen · // only N% of agents are this archetype-Rarität-Zeile · 8×8-Pixel-Sigil-Kachel · audit yours → failproof.ai-Fußzeile. Drei Teilen-Schaltflächen befinden sich knapp außerhalb des Erfassungsbereichs: post your archetype (X Intent), share on linkedin, download poster. Die Erfassung erfolgt über html-to-image, sodass das PNG pixelgenau mit der Bildschirmdarstellung übereinstimmt (gestrichelte Rahmen, SVG-Logo-Maske, Verläufe, Schriftmetriken — alles erhalten).
  2. Stärken — ruhige ✓-Zeilenliste von Verhaltensweisen, die Ihr Agent bereits richtig macht, abgeleitet aus den Live-Audit-Daten (saubere Tool-Aufruf-Rate, keine direkten Pushes auf main, null Credential-Leaks, null Retry-Stürme) — jede wird nur angezeigt, wenn die entsprechende Richtlinie im Audit-Zeitraum eine saubere Bilanz hat.
  3. Eigenheiten — Tabelle der durchgeschlüpften Probleme, nach Schweregrad gerankt: wann · was durchgeschlüpft ist + die Richtlinie, die es abgefangen hätte · Schweregrad-Pill · gesehen, wobei die Wiederholung als new (einmal), N× seen (2–9 Mal) oder recurring (10+) angegeben wird.
  4. Verbesserungsvorschläge — ruhige Zeilenliste, eine pro empfohlener Richtlinie: Richtlinienname in Weiß, einzeilige Beschreibung, Installationsbefehl + Kopierschaltfläche auf der rechten Seite. Der Abschnittsheader lautet enable all N → projected <score> · <tier> (der Score, den Sie mit allen angewendeten Korrekturen erreichen würden), und die Schaltfläche [install all] kopiert den kombinierten failproofai policy add a b c …-Befehl für jede empfohlene Richtlinie.
  5. Komm besser zurück — zwei nebeneinander stehende Karten. Links: Erinnerung setzen (3d / 7d / 14d / 30d Kadenz-Auswahl; wird nach Authentifizierung über /api/auth/reminder gespeichert). Rechts: failproof-Vorteile freischalten — invite a friend öffnet ein Modal, das eine komma-, leerzeichen- oder zeilengetrennte Liste von Freundes-E-Mails akzeptiert (max. 10 pro Sendung), sendet sie per POST an /api/audit/invite, was an den POST /v0/invite des API-Servers weitergeleitet wird. Der API-Server sendet eine E-Mail pro Empfänger von invite@failproof.ai mit dem Absender in Cc und gesetztem Reply-To, sodass der Empfänger sieht, wer ihn eingeladen hat, und der Absender eine Kopie in seinem Posteingang erhält. Anonyme Benutzer werden zunächst durch den AuthDialog geleitet, damit die E-Mail-Adresse des Absenders bekannt ist, bevor Einladungen verschickt werden. Berechtigungs-/Vorteils-Einlösung ist ein Folgeschritt.
Wird von der failproofai audit-Laufzeit gesteuert — 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, einzelner Slot, neue Läufe überschreiben), sodass erneute Besuche 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 nie stillschweigend ein wochenaltes Ergebnis ausliefert — nach Ablauf der TTL fällt /audit in seinen Leerzustand zurück und fordert einen neuen Lauf an. Ein Klick auf [ re-audit now ] am unteren Ende 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 stillschweigend das gecachte Ergebnis zurückzugeben — und das Dashboard fragt /api/audit/status mit 1Hz ab, bis der Lauf abgeschlossen ist; während des Laufs heftet sich ein pinker Fortschrittsstreifen mit einem Zeitmesser oben im Viewport fest, und das neue Ergebnis tauscht sich bei Erfolg an Ort und Stelle aus (kein vollständiges Neuladen der Seite; ein fehlgeschlagener Re-Audit lässt den vorherigen Bericht intakt). Bei einem Fehler wird der Streifen rot mit einem Text, der auf RerunError.kind (timeout / network / post_failed) basiert. Leerzustand (kein Cache oder abgelaufen) und Null-Sitzungen-Zustand (Cache vorhanden, aber der Scan fand keine Transkripte) werden separat angezeigt.

​
Richtlinien

Eine zweiseitige Seite zur Verwaltung von Richtlinien und Überprüfung von Aktivitäten.
  • Wählen Sie über ein einzelnes Panel aus, welche Agent-CLIs failproofai schützt — Claude Code, OpenAI Codex, GitHub Copilot, Cursor Agent, OpenCode, Pi und Hermes haben je eine Zeile mit Installationsstatus (Active / Detected / Inactive), dem benutzerspezifischen Einstellungspfad und einem markenspezifischen Akzent. Aktivieren oder deaktivieren Sie die gewünschten CLIs und klicken Sie auf Apply changes, um die Änderungen in einem Schritt zu installieren/deinstallieren. CLIs, deren Binary im PATH erkannt wird, sind vorausgewählt.
  • Einzelne Richtlinien mit einem einzigen Klick ein- oder ausschalten (schreibt in ~/.failproofai/policies-config.json — geteilt von allen installierten CLIs)
  • Eine Richtlinie erweitern, um ihre Parameter zu konfigurieren (für Richtlinien, die policyParams unterstützen)
  • Einen benutzerdefinierten Richtliniendatei-Pfad festlegen

​
Automatische Aktualisierung

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

​
Seiten deaktivieren

Wenn Sie nur bestimmte Teile des Dashboards benötigen, setzen Sie FAILPROOFAI_DISABLE_PAGES auf eine kommagetrennte Liste von Seitennamen:
Gültige Werte: policies, projects, audit.

​
Projektpfad konfigurieren

Standardmäßig liest das Dashboard aus dem Standard-Claude Code-Projektverzeichnis. Überschreiben Sie es für benutzerdefinierte Setups:

​
Zugriff von einem Nicht-localhost-Host

Wenn Sie das Dashboard im Dev-Modus (npm run dev) betreiben und von einem anderen Hostnamen als localhost darauf zugreifen — zum Beispiel einer benutzerdefinierten Domain, einer Remote-IP oder einer getunnelten URL — sehen Sie möglicherweise eine Warnung wie:
Dies ist Next.js, das den ursprungsübergreifenden Zugriff auf seinen HMR-Websocket (Hot Module Reload) blockiert, was eine reine Dev-Funktion ist. Um Ihren Host zuzulassen, verwenden Sie das --allowed-origins-Flag:
Für mehrere Hosts oder IPs übergeben Sie eine kommagetrennte Liste:
Sie können auch die Umgebungsvariable FAILPROOFAI_ALLOWED_DEV_ORIGINS verwenden:
Dies gilt nur für den Dev-Modus. Beim Ausführen von failproofai (Produktionsmodus) gibt es keinen HMR-Websocket und kein ursprungsübergreifendes Dev-Ressourcenproblem.