« Veuillez ne modifier que les brouillons » est une consigne de travail sensée. Mais ce n’est pas encore un point de contrôle technique. Un hook peut appliquer une règle récurrente au moment où une action précise a été préparée. Une demande générale devient ainsi une décision vérifiable portant sur un appel d’outil donné.
La référence de Claude Code décrit, entre autres événements, PreToolUse : il survient après la création des paramètres de l’outil et avant le traitement de l’appel. Le hook peut renvoyer une décision. Les exemples suivants expliquent une ébauche de notre cru ; aucune configuration de hook n’a été installée ni exécutée pour ceux-ci.
Quelles informations sont disponibles au point de décision ?
Notre projet d’apprentissage contient un dossier de brouillons et, à côté, un fichier de référence. L’agent ne doit modifier que les brouillons. Une règle sensée examine donc la cible précise d’une action d’écriture. Elle ne décide pas si l’ensemble du contenu de la conversation est digne de confiance.
L’interface fournit le nom de l’outil et l’entrée. Pour une requête de fichier appropriée, la cible peut en être déduite. Un outil inconnu ou une entrée incompréhensible devrait déclencher un état qui lui est propre. Une erreur silencieuse dans le programme de vérification ne doit pas ressembler à un chemin vérifié avec succès.
Une décision est une valeur de retour structurée
Voici à quoi ressemble une valeur de refus illustrative dans la structure PreToolUse documentée. Le motif est formulé par nos soins ; il décrit la règle locale, et non une évaluation générale de l’utilisateur.
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "The target file is outside the drafts area."
}
}Cet extrait est la valeur de retour, pas un programme de vérification complet. Il ne contient ni l’enregistrement du hook, ni la lecture et la vérification de l’entrée. C’est justement cette séparation qui est utile : la règle, l’évaluation technique et la sortie de l’interface peuvent être examinées indépendamment.
L’appartenance à un chemin ne se réduit pas à un préfixe correspondant
Une simple comparaison de chaînes de caractères peut confondre des dossiers voisins aux noms similaires. Votre propre règle devrait donc travailler avec des chemins résolus sans ambiguïté et vérifier si la cible appartient réellement au dossier racine prévu. Les différents séparateurs et les liens doivent être pris en compte dans l’environnement utilisé.
own rule logic, schematic:
Input fully readable? Otherwise check status unknown.
Tool belongs to the write path being handled? Otherwise not checked.
Resolve target and permitted root unambiguously.
Target really inside the root? Otherwise deny.
Assess only the specific call being handled.Cette esquisse ne prétend délibérément pas offrir une protection complète. Les programmes externes en particulier, qui modifient eux-mêmes d’autres fichiers, demandent une réflexion différente de celle d’un simple champ de fichier. Un fichier de départ autorisé ne dit encore rien des actions ultérieures qu’exécute un script.
Quatre tests rendent la portée visible
Dans un projet jetable, créez un fichier autorisé, une référence protégée et un dossier voisin portant un nom similaire. Ajoutez une entrée invalide. Pour chaque cas, notez au préalable quelle décision est attendue. Examinez ensuite à la fois la valeur de retour et l’exécution réelle.
Testez également une défaillance du programme de vérification lui-même. Le comportement en cas de défaillance dépend de l’événement et de la configuration et fait donc partie de l’acceptation. L’absence de message ne prouve pas que la règle a été vérifiée avec succès.
Pour chaque test, notez aussi si le hook a été atteint ou non. Une action qui emprunte un autre chemin peut contourner la règle sans que la vérification interne des chemins ait mal fonctionné.
Un hook n’est pas un cadre de protection complet
PreToolUse concerne les appels d’outils. Du contexte peut entrer dans la session par d’autres voies ; la référence actuelle décrit explicitement des limites à cet égard. Un hook ne remplace donc ni les autorisations ni le contrôle de l’environnement, et ce n’est pas une protection générale contre l’injection de prompt.
Commencez par une seule règle locale et documentez les voies qu’elle couvre et celles qu’elle ne couvre pas. Le gain technique réside dans un point de contrôle compréhensible. Seul un essai réel avec les interfaces appropriées peut montrer si ce point de contrôle est correctement mis en place dans votre version.
Sources et état de la documentation : 25 octobre 2026.
