Passer au contenu principal
Le dashboard failproofai est une application web locale permettant de surveiller vos sessions d’agents IA et de gérer vos politiques. Voyez ce que vos agents ont fait pendant votre absence.

​
Démarrer le dashboard

failproofai
S’ouvre à l’adresse http://localhost:8020. Le dashboard lit directement depuis le système de fichiers — vos dossiers de projets Claude Code et les fichiers de configuration failproofai. Rien n’est écrit vers un service distant.

​
Pages

​
Projets

Liste tous les projets Claude Code, OpenAI Codex, GitHub Copilot CLI (bêta), Cursor Agent (bêta), OpenCode (bêta), Pi (bêta) et Gemini CLI (bêta) trouvés sur votre machine. Les projets Claude sont découverts depuis ~/.claude/projects/ (ou le chemin défini par CLAUDE_PROJECTS_PATH) ; les projets Codex sont découverts en parcourant toutes les transcriptions sous ~/.codex/sessions/<YYYY>/<MM>/<DD>/*.jsonl et en les regroupant selon le cwd enregistré dans le premier enregistrement de chaque session ; les projets Copilot CLI sont découverts en parcourant chaque ~/.copilot/session-state/<sessionId>/workspace.yaml (configurable via COPILOT_HOME) et en les regroupant par leur champ cwd ; les projets Cursor Agent sont découverts en parcourant les métadonnées par session sous ~/.cursor/agent-sessions/<sessionId>/ (configurable via CURSOR_HOME, avec conversations/ et sessions/ explorés en fallback) pour un scalaire cwd dans meta.json / session.json / workspace.yaml ; les projets OpenCode sont découverts en interrogeant sa base SQLite à ~/.local/share/opencode/opencode.db via opencode db --format json (on lit les tables session et project et on regroupe par project_id) ; les projets Pi sont découverts en parcourant les transcriptions JSONL par session sous ~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<uuid>.jsonl (configurable via PI_SESSIONS_DIR) et en extrayant le cwd du premier enregistrement de chaque session ; les projets Gemini CLI sont découverts en parcourant ~/.gemini/tmp/<basename>/chats/session-<timestamp>-<uuid-prefix>.jsonl (configurable via GEMINI_SESSIONS_DIR) et en récupérant le cwd canonique depuis le marqueur texte .project_root voisin. Un projet utilisé par plusieurs CLIs s’affiche sur une seule ligne avec tous les badges correspondants. Utilisez le menu déroulant CLI au-dessus du tableau pour filtrer par agent CLI spécifique ; l’URL conserve votre sélection sous la forme ?cli=claude|codex|copilot|cursor|opencode|pi|gemini. Chaque projet affiche :
  • Le nom du projet (dérivé du chemin du dossier)
  • Un badge CLI — Claude Code (orange), OpenAI Codex (violet), GitHub Copilot (bleu), Cursor Agent (émeraude), OpenCode (ambre), Pi (rose) et/ou Gemini CLI (ciel)
  • La date de la dernière activité de session
Cliquez sur un projet pour voir ses sessions.

​
Sessions

Liste toutes les sessions d’un projet. Chaque session affiche :
  • L’identifiant de session
  • Les horodatages de début et de fin
  • Le nombre d’appels d’outils
  • Le nombre d’activités de hook (politiques déclenchées)
Utilisez le filtre par plage de dates et la recherche par identifiant de session pour affiner la liste. Les sessions sont paginées. Cliquez sur une session pour ouvrir le visualiseur de session.

​
Visualiseur de session

Le visualiseur de session répond à la question clé pour les agents autonomes : qu’a fait l’agent, et est-il resté dans les rails ? Un badge CLI à côté de l’en-tête indique si la session est une transcription Claude Code, OpenAI Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Pi ou Gemini CLI. Il affiche une chronologie de tout ce qui s’est passé dans une session :
  • Messages - Les réponses textuelles de Claude et les invites utilisateur
  • Appels d’outils - Chaque outil invoqué par Claude, avec ses entrées et sorties
  • Activité des politiques - Pour chaque appel d’outil, quelles politiques ont été déclenchées et quelle décision elles ont retournée
La barre de statistiques en haut affiche la durée de la session, le nombre total d’appels d’outils et un résumé des décisions de hook (comptages allow / deny / instruct). Cliquez sur le bouton Télécharger les logs pour exporter la session. Pour les sessions Claude Code, Codex, Copilot, Cursor, Pi et Gemini, vous obtenez la transcription JSONL originale sur disque octet par octet ; pour OpenCode (dont les sessions résident dans SQLite et non sur disque), vous obtenez un document JSON reflétant les tables sous-jacentes session / messages / parts.

​
Audit

Un rapport personnalisé de la façon dont votre agent s’est réellement comporté au fil des sessions passées. Effectue le même scan que la CLI failproofai audit mais le restitue sous forme d’un dashboard en six sections :
  1. Identité — classe votre agent dans l’un des 8 archétypes (the optimist, the cowboy, the explorer, the goldfish, the paranoid architect, the precision builder, the hammer, the ghost) selon les détecteurs et politiques déclenchés et leur fréquence. Affiche un sigil de 8×8 pixels, la tagline de l’archétype, un encadrement « common in » / « primary risk », et la phrase de conclusion.
  2. Mettez votre agent en valeur — capture la carte d’identité en PNG 1200×630 adapté à la publication sur X / LinkedIn (cliquez sur make poster).
  3. Points forts — comportements validés (coches vertes) que votre agent fait déjà correctement, dérivés des données d’audit en direct (taux d’appels d’outils propres, durée moyenne des sessions, zéro fuite de credentials, zéro tempête de tentatives, etc.).
  4. Score + classement — score de 0 à 100 avec mention (S/A/B/C/D/F), un histogramme de distribution montrant votre position dans la cohorte, un commentaire en prose (« a B starts at 71. you’re 13 points away. »), et un tableau de classement avec votre ligne mise en évidence.
  5. Constats — fiches par constat classées par impact. Chaque fiche expose ce qui s’est passé, ce que cela coûte, un échantillon de preuve avec des commandes réellement capturées, et la politique failproofai qui intercepterait le même schéma ($ failproofai policy add <slug>, cliquer pour copier).
  6. Politiques prescrites + boucle de retour — une grille de chaque politique intégrée non activée qui comblerait un manque, avec une projection de score, plus un appel à l’action « re-audit dans 7 jours ».
Alimenté par le moteur d’exécution failproofai audit — voir Audit CLI pour le moteur de scan sous-jacent, les options supportées et les invariants de cache par transcription. Le dashboard met en cache le dernier résultat dans ~/.failproofai/audit-dashboard.json (mode 0600, emplacement unique, les nouvelles exécutions écrasent) pour des revisites instantanées ; les deux caches (par transcription et résultat global) sont rejetés à la lecture s’ils ont plus de 7 jours afin que le dashboard ne serve jamais silencieusement un résultat vieux d’une semaine — passé ce TTL, /audit revient à son état vide et invite à une nouvelle exécution. Cliquer sur [ re-audit now ] en bas du rapport envoie un POST à /api/audit/run avec noCache: true — le re-audit contourne le cache par transcription et rescanne chaque transcription depuis zéro plutôt que de retourner silencieusement le résultat en cache — et le dashboard interroge /api/audit/status à 1 Hz jusqu’à la fin de l’exécution ; une banderole rose épinglée en haut de la fenêtre s’affiche pendant l’exécution avec un chronomètre, et le nouveau résultat remplace l’ancien en place en cas de succès (sans rechargement complet de la page ; un re-audit échoué laisse le rapport précédent intact). En cas d’échec, la banderole devient rouge avec un message basé sur RerunError.kind (timeout / network / post_failed). L’état vide (pas de cache ou expiré) et l’état zéro-sessions (cache existant mais le scan n’a trouvé aucune transcription) sont affichés séparément.

​
Politiques

Une page à deux onglets pour gérer les politiques et examiner l’activité.
  • Sélectionnez plusieurs agents CLIs que failproofai protège depuis un seul panneau — Claude Code, OpenAI Codex, GitHub Copilot, Cursor Agent, OpenCode, Pi et Gemini CLI ont chacun une ligne avec le statut d’installation (Active / Detected / Inactive), le chemin des paramètres à portée utilisateur et un accent coloré à leur image. Cochez ou décochez les CLIs souhaités et cliquez sur Apply changes pour installer/désinstaller le diff en une seule étape. Les CLIs dont le binaire est détecté dans le PATH sont pré-cochés.
  • Activez ou désactivez individuellement les politiques d’un simple clic (écrit dans ~/.failproofai/policies-config.json — partagé entre tous les CLIs installés)
  • Développez une politique pour configurer ses paramètres (pour les politiques supportant policyParams)
  • Définissez un chemin de fichier de politiques personnalisées

​
Actualisation automatique

Le dashboard dispose d’un bouton d’actualisation automatique dans la navigation principale. Lorsqu’il est activé, la page courante se rafraîchit périodiquement pour afficher les nouvelles sessions et l’activité des politiques au fur et à mesure. Indispensable pour surveiller des sessions d’agents autonomes de longue durée.

​
Désactiver des pages

Si vous n’avez besoin que de certaines parties du dashboard, définissez FAILPROOFAI_DISABLE_PAGES avec une liste de noms de pages séparés par des virgules : 
FAILPROOFAI_DISABLE_PAGES=policies failproofai
Valeurs valides : policies, projects, audit.

​
Configurer le chemin des projets

Par défaut, le dashboard lit depuis le répertoire de projets Claude Code standard. Remplacez-le pour des configurations personnalisées : 
CLAUDE_PROJECTS_PATH=/custom/path/to/projects failproofai

​
Accès depuis un hôte autre que localhost

Lorsque vous exécutez le dashboard en mode dev (npm run dev) et y accédez depuis un nom d’hôte autre que localhost — par exemple, un domaine personnalisé, une IP distante ou une URL tunnelisée — vous pouvez voir un avertissement du type : 
⚠ Blocked cross-origin request to Next.js dev resource /_next/webpack-hmr from "dashboard.example.com".
Il s’agit de Next.js qui bloque l’accès cross-origin à son websocket HMR (hot module reload), une fonctionnalité réservée au mode dev. Pour autoriser votre hôte, utilisez l’option --allowed-origins : 
npm run dev -- --allowed-origins dashboard.example.com
Pour plusieurs hôtes ou IPs, passez une liste séparée par des virgules : 
npm run dev -- --allowed-origins dashboard.example.com,192.168.1.5
Vous pouvez également définir la variable d’environnement FAILPROOFAI_ALLOWED_DEV_ORIGINS à la place : 
FAILPROOFAI_ALLOWED_DEV_ORIGINS=dashboard.example.com npm run dev
Ceci s’applique uniquement au mode dev. Lors de l’exécution de failproofai (mode production), il n’y a pas de websocket HMR ni de problème de ressource dev cross-origin.