Les Hooks sont conçus pour les utilisateurs avancés et les équipes Enterprise qui ont besoin d’un contrôle précis sur le comportement de Cascade. Ils nécessitent des connaissances de base en scripting shell.
- Journalisation et Analytics : suivez chaque fichier lu, chaque modification de code, chaque commande exécutée, chaque invite utilisateur ou chaque réponse de Cascade pour la conformité et l’analyse de l’usage
- Contrôles de sécurité : empêchez Cascade d’accéder à des fichiers sensibles, d’exécuter des commandes dangereuses ou de traiter des invites qui enfreignent les politiques
- Assurance qualité : exécutez automatiquement des linters, des formateurs ou des tests après des modifications de code
- Workflows personnalisés : intégrez-vous aux outils de suivi d’incidents, aux systèmes de notification ou aux pipelines de déploiement
- Standardisation d’équipe : appliquez des normes de codage et des meilleures pratiques dans toute votre organisation
- Reçoit un contexte (des détails sur l’action en cours) au format JSON via l’entrée standard
- Exécute votre script — Python, Bash, Node.js ou tout exécutable
- Renvoie un résultat via le code de sortie et les flux de sortie
2. Les pré-hooks sont donc idéaux pour appliquer des politiques de sécurité ou effectuer des validations.
Les hooks sont configurés dans des fichiers JSON pouvant être placés à trois niveaux différents. Cascade charge et fusionne les hooks à partir de tous ces emplacements, offrant aux équipes la flexibilité nécessaire pour distribuer et gérer les configurations de hooks.
Les hooks au niveau système sont idéaux pour des politiques à l’échelle de l’organisation, appliquées sur des machines de développement partagées. Par exemple, vous pouvez les utiliser pour appliquer des politiques de sécurité, des exigences de conformité ou des workflows de revue de code obligatoires. Les équipes Enterprise peuvent également configurer des hooks via le cloud dashboard sans avoir à gérer de fichiers locaux.
- macOS :
/Library/Application Support/Windsurf/hooks.json - Linux/WSL :
/etc/windsurf/hooks.json - Windows :
C:\ProgramData\Windsurf\hooks.json
- Emplacement :
~/.codeium/windsurf/hooks.json - Plugin JetBrains :
~/.codeium/hooks.json
- Emplacement :
.windsurf/hooks.jsonà la racine de votre workspace
Les hooks provenant des trois emplacements sont fusionnés. Si le même événement de hook est configuré à plusieurs emplacements, tous les hooks s’exécuteront dans l’ordre : système → utilisateur → workspace.
À propos du paramètre
working_directory :- Dans les workspaces comportant plusieurs dépôts, la valeur par défaut est la racine du dépôt actuellement en cours d’utilisation
- Les chemins relatifs sont résolus à partir de l’emplacement par défaut (racine du workspace ou du dépôt)
- Les chemins absolus sont pris en charge
- L’utilisation de
~pour développer le chemin vers le répertoire personnel n’est pas prise en charge
Dans les exemples suivants, les champs communs sont omis pour plus de concision. Il existe douze grands types d’événements de hook :
Déclenché avant que Cascade ne lise un fichier de code. L’action peut être bloquée si le hook se termine avec le code 2.
Cas d’usage : Restreindre l’accès aux fichiers, consigner les opérations de lecture, vérifier les autorisations
JSON d’entrée :
file_path peut être un chemin de répertoire lorsque Cascade parcourt un répertoire de façon récursive.
Déclenché après que Cascade a lu un fichier de code avec succès.
Cas d’usage : consigner les lectures réussies, suivre les schémas d’accès aux fichiers
JSON d’entrée :
file_path peut être un chemin de répertoire lorsque Cascade lit un répertoire de façon récursive.
Déclenché avant que Cascade n’écrive ou ne modifie un fichier de code. Cela peut bloquer l’action si le hook se termine avec le code 2.
Cas d’utilisation : Empêcher les modifications de fichiers protégés, sauvegarder les fichiers avant les changements
Input JSON:
show_output ne s’applique pas à ce hook.
Déclenché de manière asynchrone après que Cascade a terminé de répondre à la requête d’un utilisateur. Ce hook reçoit l’intégralité de la réponse générée par Cascade depuis la dernière saisie de l’utilisateur.
Cas d’utilisation : journaliser toutes les réponses de Cascade pour audit, analyser les schémas de réponse, envoyer les réponses à des systèmes externes pour examen de conformité
JSON d’entrée :
response contient le contenu au format Markdown de la réponse de Cascade depuis la dernière saisie de l’utilisateur. Cela inclut les réponses du planificateur, les actions d’outils (lectures et écritures de fichiers, commandes), ainsi que toute autre étape effectuée par Cascade. Il inclut également des informations sur les règles qui ont été déclenchées. Voir l’exemple Suivi des règles déclenchées pour savoir comment analyser l’utilisation des règles.
L’option de configuration show_output ne s’applique pas à ce hook.
Déclenché de manière asynchrone après que Cascade a terminé une réponse à l’invite d’un utilisateur, similaire à post_cascade_response. Au lieu de fournir un résumé markdown intégré, ce hook écrit la transcription complète de la conversation (depuis le début de la conversation) dans un fichier JSONL local et fournit le chemin du fichier.
Cas d’usage : journalisation d’audit et de conformité pour Enterprise, suivi des contributions générées par l’IA, envoi des transcriptions vers des outils externes d’observabilité ou d’Analytics
JSON d’entrée :
transcript_path pointe vers un fichier JSONL situé à ~/.windsurf/transcripts/{trajectory_id}.jsonl. Chaque ligne est un objet JSON représentant une étape de la conversation, avec des champs type et status, ainsi que des données propres à cette étape. Par exemple :
0600. Windsurf limite automatiquement le répertoire de transcriptions à 100 fichiers, en supprimant les plus anciens selon leur date de modification.
L’option de configuration show_output ne s’applique pas à ce hook.
Ce tableau présente les différences clés entre les hooks post_cascade_response et post_cascade_response_with_transcript :
Déclenché après la création et la configuration d’un nouveau git worktree. Le hook est exécuté dans le répertoire du nouveau worktree.
Cas d’utilisation : Copier les fichiers
.env ou d’autres fichiers non suivis dans le worktree, installer les dépendances, exécuter des scripts de configuration
Variables d’environnement :
JSON d’entrée :
Gardez à l’esprit que l’utilisateur peut voir toute sortie standard et toute erreur standard générées par un hook dans l’interface Cascade si
show_output est à true.
Enregistrez chaque action effectuée par Cascade à des fins d’audit.
Config :
log_input.py) :
block_read_access.py) :
block_dangerous_commands.py) :
block_bad_prompts.py) :
log_cascade_response.py) :
track_rules.py) :
Always On- Règles toujours activesModel Decision- Règles dont les descriptions ont été présentées au modèle d’IA pour une application conditionnelleManual- Règles explicitement mentionnées avec @ dans la saisie utilisateurGlobal- Règles globales provenant deglobal_rules.mdGlob- Règles déclenchées par l’accès à des fichiers correspondant à des motifs glob
Cela indique quelles règles ont été présentées au modèle d’IA ou déclenchées par l’accès aux fichiers, mais n’indique pas si le modèle d’IA a effectivement suivi une règle. Les règles déjà affichées récemment dans la conversation sont dédupliquées et peuvent ne pas réapparaître avant un certain temps.
format_code.sh) :
.windsurf/hooks.json) :
hooks/setup_worktree.sh) :
- Validez toutes les entrées : Ne faites jamais confiance au JSON d’entrée sans validation, en particulier pour les chemins de fichiers et les commandes.
- Utilisez des chemins absolus : Utilisez toujours des chemins absolus dans vos configurations de hooks pour éviter toute ambiguïté.
- Protégez les données sensibles : Évitez de journaliser des informations sensibles comme des clés d’API ou des identifiants.
- Vérifiez les permissions : Assurez-vous que vos scripts de hook disposent des permissions appropriées sur le système de fichiers.
- Auditez avant le déploiement : Passez en revue chaque commande et chaque script de hook avant de l’ajouter à votre configuration.
- Testez en isolation : Exécutez les hooks dans un environnement de test avant de les activer sur votre machine de développement principale.
- Gardez les hooks rapides : Des hooks lents dégraderont la réactivité de Cascade. Visez des temps d’exécution inférieurs à 100 ms.
- Utilisez des opérations asynchrones : Pour des hooks non bloquants, envisagez de journaliser vers une file d’attente ou une base de données de façon asynchrone.
- Filtrez dès le début : Vérifiez le type d’action au démarrage de votre script pour éviter tout traitement inutile.
- Toujours valider le JSON : Utilisez des blocs try-catch pour gérer proprement les entrées malformées.
- Journalisez correctement les erreurs : Écrivez-les sur
stderrafin qu’elles soient visibles lorsqueshow_outputest activé. - Échec sécurisé : Si votre hook rencontre une erreur, déterminez s’il doit bloquer l’action ou la laisser se poursuivre.
- Commencez par la journalisation : Implémentez d’abord un hook de journalisation simple pour comprendre le flux de données.
- Utilisez
show_output: true: Activez l’affichage de la sortie pendant le développement pour voir ce que font vos hooks. - Testez le comportement de blocage : Vérifiez que le code de sortie 2 bloque correctement les actions dans les pré-hooks.
- Couvrez tous les chemins d’exécution : Testez les scénarios de réussite comme d’échec dans vos scripts.
- Cloud Dashboard - Configurez les hooks via les paramètres d’équipe dans le tableau de bord Windsurf
- Fichiers au niveau du système - Déployez les hooks via des outils MDM ou de gestion de configuration
- Offre Enterprise
- Autorisation
TEAM_SETTINGS_UPDATE
- Accédez à Team Settings dans le tableau de bord Windsurf
- Recherchez la section Cascade Hooks
- Saisissez votre configuration de hooks au format JSON
- Enregistrez vos modifications
Lorsque plusieurs configurations d’équipe sont fusionnées, les hooks sont combinés par action plutôt que remplacés. Cela signifie que les hooks de toutes les configurations d’équipe applicables s’exécuteront ensemble.
hooks.json aux emplacements spécifiques au système d’exploitation suivants :
macOS :
/usr/local/share/windsurf-hooks/ sur les systèmes Unix).
Les hooks au niveau du système ont priorité sur les hooks utilisateur et de workspace et ne peuvent pas être désactivés par les utilisateurs finaux sans privilèges root.
Les équipes IT Enterprise peuvent déployer des hooks au niveau du système à l’aide d’outils standard :
Mobile Device Management (MDM)
- Jamf Pro (macOS) - Déployez via des profils de configuration ou des scripts
- Microsoft Intune (Windows/macOS) - Utilisez des scripts PowerShell ou un déploiement de stratégies
- Workspace ONE, Google Endpoint Management, et autres solutions MDM
- Ansible, Puppet, Chef, SaltStack - Utilisez votre automatisation d’infrastructure existante
- Scripts de déploiement personnalisés - Scripts shell, PowerShell ou l’outil de votre choix
Important : Les hooks système sont entièrement gérés par votre équipe informatique ou sécurité. Windsurf ne déploie ni ne gère de fichiers dans des emplacements système. Veillez à ce que vos équipes internes se chargent du déploiement, des mises à jour et de la conformité conformément aux politiques de votre organisation.
- Intégration MCP : En savoir plus sur le Model Context Protocol dans Windsurf
- Workflows : Découvrez comment combiner des hooks avec les workflows Cascade
- Analytics : Suivez l’utilisation de Cascade avec les Analytics d’équipe