Les règles de permission ressemblent à des globs et se comportent de façon plus étroite, et c'est là que les ennuis commencent. Une règle est confrontée à la commande telle qu'écrite, et il n'y a pas de joker final implicite : une règle couvrant une commande de test ne couvre pas la même commande avec une option ajoutée. Refuser bat demander, demander bat autoriser, et ce qui ne correspond à rien retombe sur le défaut du mode. Tout cela s'énonce facilement et se retient mal quand on écrit une douzaine de règles. Ici, on les teste : collez les règles, collez les commandes attendues, et voyez le résultat de chacune à côté de la règle qui a tranché. L'outil trouve aussi les règles qui ne peuvent jamais se déclencher, y compris une autorisation sous un refus plus large.
Fonctionnalités
Chaque commande avec son issue et la règle qui a tranché
Refuser sur demander sur autoriser, comme le vrai résolveur
Trouve les règles qui ne se déclencheront jamais faute de portée
Détecte une autorisation rendue inatteignable par un refus
Signale les lignes qui ne sont pas des règles
Montre les commandes sans correspondance plutôt que de deviner
Jokers traités tels qu’écrits — pas de correspondance finale invisible
Produit le bloc de permissions pour settings.json
Comment utiliser Testeur de règles de permission
Collez vos règles autoriser, demander et refuser
Collez les commandes que vous attendez
Lisez l’issue de chacune et la règle décisive
Copiez le bloc de permissions dans settings.json
Exemple
Entrée
Bash(npm run test)
Sortie
npm run test:unit — no rule matched
Pas de joker implicite : la règle couvre exactement cette commande.
Erreurs courantes et dépannage
Ma règle ne couvre pas la commande attendue. — Il n’y a pas de joker final. Bash(npm run test) ne correspond qu’à cette commande ; Bash(npm run test:*) couvre les variantes.
Une commande autorisée demande quand même. — Quelque chose de priorité supérieure a correspondu. Toutes les règles correspondantes sont listées pour chaque commande, dans l’ordre de résolution.
Une de mes règles est marquée inatteignable. — Une règle plus large et de priorité au moins égale couvre déjà tout. Une autorisation sous un refus large est le cas type : refuser gagne toujours, l’autorisation ne fait donc rien.
Une ligne est signalée comme n’étant pas une règle. — Les règles sont Tool ou Tool(motif). Une commande seule sans préfixe d’outil n’est pas une règle et est ignorée.
Foire aux questions
Le motif est-il un glob ou une expression régulière ?
Ni l’un ni l’autre exactement. C’est une correspondance littérale où * représente n’importe quelle suite de caractères, appliquée à la commande telle qu’écrite. La syntaxe des expressions régulières est traitée comme du texte littéral.
Que devient une commande sans règle correspondante ?
Elle retombe sur le comportement par défaut du mode de permissions courant, qui peut être demander ou autoriser. Elles s’affichent ici comme sans correspondance plutôt que devinées, car la réponse dépend du mode.
Laquelle gagne quand plusieurs correspondent ?
Refuser, puis demander, puis autoriser. Toutes les correspondances sont montrées pour chaque commande, afin de voir ce qui a été supplanté plutôt que de le déduire.
Pourquoi signaler une autorisation sous un refus ?
Parce que cette autorisation ne peut jamais prendre effet — refuser gagne toujours. On écrit ces règles en espérant une exception à un refus large, et rien n’avertit qu’elles n’ont rien fait.
Plutôt des règles d’autorisation ou de refus ?
Les refus sont ceux qui tiennent. Une liste d’autorisations rend le travail de routine silencieux ; une liste de refus empêche précisément ce que vous ne voulez jamais voir arriver, et l’emporte sur tout le reste.
Outils associés
Générateur de hooks — Créez des hooks settings.json et repérez les matchers qui ne se déclenchent jamais.
Générateur de sous-agents — Créez le fichier de définition d'un sous-agent, outils et modèle compris.
Générateur de commandes — Créez une commande personnalisée, avec arguments et liste d'outils.