Skip to main content
Il dashboard failproofai è un’applicazione web locale per monitorare le tue sessioni di agenti AI e gestire le policy. Scopri cosa hanno fatto i tuoi agenti mentre eri via.

​
Avvio del dashboard

Si apre su http://localhost:8020. Il dashboard legge i dati di configurazione del progetto locale, della sessione e di failproofai direttamente dal filesystem. Le funzionalità autenticate opzionali, come i promemoria di audit e gli inviti, inviano le informazioni necessarie per tali richieste (inclusi gli indirizzi email) a API remote.

​
Pagine

​
Progetti

Elenca tutti i progetti Claude Code, OpenAI Codex, GitHub Copilot CLI (beta), Cursor Agent (beta), OpenCode (beta), Pi (beta), Hermes, OpenClaw, Factory Droid, Devin, Antigravity e Goose trovati sulla tua macchina. I progetti Claude vengono individuati da ~/.claude/projects/ (o dal percorso impostato da CLAUDE_PROJECTS_PATH); i progetti Codex vengono individuati eseguendo la scansione di ogni trascrizione in ~/.codex/sessions/<YYYY>/<MM>/<DD>/*.jsonl e raggruppando per il cwd registrato nel primo record di ogni sessione; i progetti Copilot CLI vengono individuati eseguendo la scansione di ogni ~/.copilot/session-state/<sessionId>/workspace.yaml (configurabile tramite COPILOT_HOME) e raggruppando per il suo campo cwd; i progetti Cursor Agent vengono individuati eseguendo la scansione dei metadati per sessione in ~/.cursor/agent-sessions/<sessionId>/ (configurabile tramite CURSOR_HOME, con conversations/ e sessions/ come fallback) per uno scalare cwd in meta.json / session.json / workspace.yaml; i progetti OpenCode vengono individuati interrogando il suo DB SQLite in ~/.local/share/opencode/opencode.db tramite opencode db --format json (leggiamo le tabelle session e project e raggruppiamo per project_id); i progetti Pi vengono individuati eseguendo la scansione delle trascrizioni JSONL per sessione in ~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<uuid>.jsonl (configurabile tramite PI_SESSIONS_DIR) ed estraendo il cwd dal primo record di ogni sessione; le sessioni gateway Hermes vengono lette direttamente dal suo store SQLite in ~/.hermes/state.db (configurabile tramite HERMES_DB_PATH) e raggruppate in progetti hermes-<source> per source (Slack/Telegram/cli/cron — le sessioni gateway non hanno cwd); le sessioni gateway OpenClaw vengono lette da ~/.openclaw/agents/<agentId>/sessions/*.jsonl e raggruppate in progetti openclaw-<agentId> (anche senza cwd); i progetti Factory Droid vengono individuati dalle trascrizioni JSONL in ~/.factory/sessions/<encoded-cwd>/*.jsonl e raggruppati per cwd; i progetti Devin dal suo DB SQLite in ~/.local/share/devin/cli/sessions.db (raggruppati per working_directory di ogni sessione); i progetti Antigravity dalle trascrizioni JSONL in ~/.gemini/antigravity-cli/brain/<conversationId>/…/transcript_full.jsonl e raggruppati per cwd; e i progetti Goose dal suo DB SQLite in ~/.local/share/goose/sessions/sessions.db (raggruppati per working_dir di ogni sessione). Un progetto che è stato utilizzato da più CLI viene visualizzato come una singola riga con tutti i badge corrispondenti. Usa il menu a discesa CLI sopra la tabella per filtrare per uno specifico agent CLI; l’URL mantiene la tua selezione come ?cli=claude|codex|copilot|cursor|opencode|pi|hermes|openclaw|factory|devin|antigravity|goose. Ogni progetto mostra:
  • Nome del progetto (derivato dal percorso della cartella)
  • Un badge CLI — Claude Code (arancione), OpenAI Codex (viola), GitHub Copilot (blu), Cursor Agent (smeraldo), OpenCode (ambra), Pi (rosa), e/o Hermes (indaco)
  • Data dell’attività di sessione più recente
Fai clic su un progetto per visualizzare le sue sessioni.

​
Sessioni

Elenca tutte le sessioni all’interno di un progetto. Ogni sessione mostra:
  • ID sessione
  • Timestamp di inizio e fine
  • Numero di chiamate ai tool
  • Conteggio dell’attività degli hook (policy che sono state attivate)
Utilizza il filtro per intervallo di date e la ricerca per ID sessione per restringere l’elenco. Le sessioni sono impaginate. Fai clic su una sessione per aprire il visualizzatore di sessione.

​
Visualizzatore di sessione

Il visualizzatore di sessione risponde alla domanda chiave per gli agenti autonomi: cosa ha fatto l’agente e è rimasto in traccia? Un badge CLI accanto all’intestazione indica se la sessione è una trascrizione Claude Code, OpenAI Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Pi, Hermes, OpenClaw, Factory Droid, Devin, Antigravity o Goose. Mostra una cronologia di tutto ciò che è accaduto in una sessione:
  • Messaggi - Risposte di testo di Claude e prompt dell’utente
  • Chiamate ai tool - Ogni tool invocato da Claude, con il suo input e output
  • Attività delle policy - Per ogni chiamata ai tool, quali policy sono state attivate e quale decisione hanno restituito
La barra delle statistiche in alto mostra la durata della sessione, il numero totale di chiamate ai tool e un riepilogo delle decisioni degli hook (conteggi allow / deny / instruct). Fai clic sul pulsante Download Logs per esportare la sessione. Per le sessioni Claude Code, Codex, Copilot, Cursor e Pi ottieni la trascrizione JSONL originale su disco byte per byte; per OpenCode (le cui sessioni risiedono in SQLite, non su disco) ottieni un documento JSON che rispecchia le tabelle sottostanti session / messages / parts.

​
Audit

Un rapporto guidato dalla personalità su come il tuo agente si è effettivamente comportato nelle sessioni passate. Esegue la stessa scansione dell’utility CLI failproofai audit ma la visualizza come un poster condivisibile a schermo singolo + quattro sezioni sotto il margine di piega:
  1. Poster — riempie il primo viewport. Regione di cattura PNG autonoma con il wordmark failproof_ai + etichetta audit · indice archetipo (№ NN di 08) + data audit · punteggio numerico (0–100) + pillola di classificazione percentile (top 15%) · il nome dell’archetipo (uno di the optimist, the cowboy, the explorer, the goldfish, the paranoid architect, the precision builder, the hammer, the ghost) + striscia di 3 parole chiave · // solo il N% degli agenti è questo archetipo riga di rarità · sigillo in piastrella di 8×8 pixel · piè di pagina audit yours → failproof.ai. Tre pulsanti di condivisione si trovano appena fuori dalla casella di cattura: post your archetype (intent X), share on linkedin, download poster. La cattura viene eseguita attraverso html-to-image quindi il PNG corrisponde al rendering sullo schermo pixel per pixel (bordi tratteggiati, maschera logo SVG, gradienti, metriche dei caratteri — tutto conservato).
  2. Strengths — elenco di righe calme ✓ di comportamenti che il tuo agente già fa bene, derivati dai dati di audit live (tasso di chiamata dei tool pulito, nessun push diretto a main, zero perdite di credenziali, zero tempeste di retry) — ognuno visualizzato solo quando la policy pertinente ha un record pulito nell’intervallo di audit.
  3. Quirks — tabella di ciò che è sfuggito, classificata per gravità: when · what slipped + the policy that would've caught it · severity pill · seen, dove la ricorrenza legge new (una volta), N× seen (2–9 volte), o recurring (10+).
  4. How to improve — elenco di righe calme, uno per policy prescritta: nome della policy in bianco, descrizione di una riga, comando di installazione + pulsante di copia sul lato destro. L’intestazione della sezione legge enable all N → projected <score> · <tier> (il punteggio che raggiungeresti con ogni correzione applicata), e il suo pulsante [install all] copia il comando combinato failproofai policy add a b c … per ogni policy prescritta.
  5. Come back better — due schede affiancate. Sinistra: imposta un promemoria (selettore di cadenza 3d / 7d / 14d / 30d; persiste tramite /api/auth/reminder una volta autenticato). Destra: sblocca i vantaggi failproof — invite a friend apre un modale che accetta un elenco separato da virgole/spazi/newline di email amiche (max 10 per invio), le POST a /api/audit/invite, che inoltrano al /v0/invite del server api. Il server api invia un email per destinatario da invite@failproof.ai con il mittente in Cc e Reply-To impostato, quindi il destinatario vede chi lo ha invitato e il mittente riceve una copia nella sua inbox. Gli utenti anonimi vengono instradati attraverso AuthDialog prima in modo che l’email del mittente sia nota prima che gli inviti vengano inviati. La realizzazione dei diritti / vantaggi è un follow-up.
Gestito dal runtime failproofai audit — vedere Audit CLI per il motore di scansione sottostante, i flag supportati e gli invarianti di cache per trascrizione. Il dashboard memorizza nella cache il risultato più recente in ~/.failproofai/audit-dashboard.json (modalità 0600, slot singolo, i nuovi run sovrascrivono) quindi i revisit sono istantanei; sia la cache per trascrizione che il risultato complessivo vengono rifiutati alla lettura una volta che hanno più di 7 giorni quindi il dashboard non serve mai in silenzio un risultato vecchio di una settimana — dopo il TTL /audit ricade nel suo stato vuoto e richiede una nuova esecuzione. Facendo clic su [ re-audit now ] vicino al fondo del rapporto POST su /api/audit/run con noCache: true — il re-audit ignora la cache per trascrizione e scansiona ogni trascrizione da zero piuttosto che restituire silenziosamente il risultato memorizzato nella cache — e il dashboard esegue il polling su /api/audit/status a 1Hz fino al completamento dell’esecuzione; una striscia di progresso rosa appiccicosa si fissa nella parte superiore del viewport durante l’esecuzione con un timer trascorso, e il risultato aggiornato si sostituisce in posizione al successo (nessun ricarico della pagina intera; un re-audit fallito lascia il rapporto precedente intatto). In caso di errore la striscia diventa rossa con la copia basata su RerunError.kind (timeout / network / post_failed). Lo stato vuoto (nessuna cache o scaduta) e lo stato zero-sessioni (cache esiste ma la scansione non ha trovato trascrizioni) vengono visualizzati separatamente.

​
Policy

Una pagina a due schede per gestire le policy e rivedere l’attività.
  • Selezione multipla di quali agent CLI failproofai protegge da un singolo pannello — Claude Code, OpenAI Codex, GitHub Copilot, Cursor Agent, OpenCode, Pi e Hermes hanno tutti una riga con stato di installazione (Active / Detected / Inactive), il percorso delle impostazioni nell’ambito dell’utente e un accento di marca colorato. Seleziona o deseleziona i CLI che desideri e fai clic su Apply changes per installare/disinstallare la differenza in un unico passaggio. I CLI il cui binario è rilevato su PATH vengono pre-selezionati.
  • Attiva o disattiva le singole policy con un singolo clic (scrive su ~/.failproofai/policies-config.json — condiviso tra ogni CLI installato)
  • Espandi una policy per configurare i suoi parametri (per le policy che supportano policyParams)
  • Imposta un percorso file delle policy personalizzato

​
Auto-refresh

Il dashboard ha un interruttore di auto-refresh nella navigazione superiore. Quando abilitato, la pagina corrente si aggiorna periodicamente per mostrare nuove sessioni e attività di policy man mano che appaiono. Essenziale per monitorare le sessioni di agenti autonomi di lunga durata.

​
Disabilitazione delle pagine

Se hai bisogno solo di alcune parti del dashboard, imposta FAILPROOFAI_DISABLE_PAGES su un elenco separato da virgole di nomi di pagine:
Valori validi: policies, projects, audit.

​
Configurazione del percorso dei progetti

Per impostazione predefinita, il dashboard legge dalla directory dei progetti Claude Code standard. Sovrascrivi per configurazioni personalizzate:

​
Accesso da un host non-localhost

Quando si esegue il dashboard in modalità dev (npm run dev) e si accede da un nome host diverso da localhost - ad esempio, un dominio personalizzato, un IP remoto o un URL con tunnel — potresti visualizzare un avviso come:
Questo è Next.js che blocca l’accesso cross-origin al suo websocket HMR (hot module reload), che è una funzionalità solo per lo sviluppo. Per consentire il tuo host, usa il flag --allowed-origins:
Per più host o IP, passa un elenco separato da virgole:
Puoi anche impostare la variabile d’ambiente FAILPROOFAI_ALLOWED_DEV_ORIGINS:
Questo si applica solo alla modalità dev. Quando si esegue failproofai (modalità produzione), non c’è websocket HMR e nessun problema di risorsa dev cross-origin.