> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Dashboard

> Agent-Sitzungen überwachen, Tool-Aufrufe einsehen und Richtlinien verwalten

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

```bash theme={null}
failproofai
```

Ö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](/de/cli/audit) 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.

<Tabs>
  <Tab title="Richtlinien-Tab">
    * 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
  </Tab>

  <Tab title="Aktivitäts-Tab">
    * Vollständiger paginierter Verlauf jedes Hook-Ereignisses, das über alle Sitzungen hinweg ausgelöst wurde
    * Filtern nach Entscheidung, Ereignistyp, CLI (Claude Code / OpenAI Codex / GitHub Copilot *(Beta)* / Cursor Agent *(Beta)* / OpenCode *(Beta)* / Pi *(Beta)* / Hermes / OpenClaw / Factory Droid / Devin / Antigravity / Goose), Richtlinienname oder Sitzungs-ID
    * Jede Zeile zeigt: Zeitstempel, Richtlinienname, Entscheidung, CLI-Badge (orange = Claude Code, lila = OpenAI Codex, blau = GitHub Copilot, smaragdgrün = Cursor Agent, bernstein = OpenCode, pink = Pi, indigo = Hermes, türkis = OpenClaw, rose = Factory Droid, violett = Devin, cyan = Antigravity, lindgrün = Goose), Tool-Name, Sitzungs-ID und der Grund für deny/instruct-Entscheidungen
    * Klicken Sie auf eine Sitzungs-ID, um ihr Transkript zu öffnen — der Viewer erkennt automatisch, welche CLI den Hook ausgelöst hat (Claude `~/.claude/projects/…`, Codex `~/.codex/sessions/…`, Copilot CLI `~/.copilot/session-state/<id>/events.jsonl`, Cursor Agent `~/.cursor/agent-sessions/<id>/events.jsonl`, OpenCode `~/.local/share/opencode/opencode.db`, Pi `~/.pi/agent/sessions/<encoded-cwd>/<id>.jsonl`, Hermes `~/.hermes/state.db`, OpenClaw `~/.openclaw/agents/<id>/sessions/*.jsonl`, Factory Droid `~/.factory/sessions/<encoded-cwd>/<id>.jsonl`, Devin `~/.local/share/devin/cli/sessions.db`, Antigravity `~/.gemini/antigravity-cli/brain/<id>/…/transcript_full.jsonl`, Goose `~/.local/share/goose/sessions/sessions.db`) und zeigt das passende CLI-Badge im Header an
  </Tab>
</Tabs>

***

## 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:

```bash theme={null}
FAILPROOFAI_DISABLE_PAGES=policies failproofai
```

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:

```bash theme={null}
CLAUDE_PROJECTS_PATH=/custom/path/to/projects failproofai
```

***

## 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:

```text theme={null}
⚠ Blocked cross-origin request to Next.js dev resource /_next/webpack-hmr from "dashboard.example.com".
```

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:

```bash theme={null}
npm run dev -- --allowed-origins dashboard.example.com
```

Für mehrere Hosts oder IPs übergeben Sie eine kommagetrennte Liste:

```bash theme={null}
npm run dev -- --allowed-origins dashboard.example.com,192.168.1.5
```

Sie können auch die Umgebungsvariable `FAILPROOFAI_ALLOWED_DEV_ORIGINS` verwenden:

```bash theme={null}
FAILPROOFAI_ALLOWED_DEV_ORIGINS=dashboard.example.com npm run dev
```

<Note>
  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.
</Note>
