Las reglas de permisos parecen globs y se comportan como algo más estrecho, y ahí empieza el problema. Una regla se compara con el comando tal como está escrito, y no hay comodín final implícito: una regla que cubre un comando de pruebas no cubre ese mismo comando con una opción al final. Denegar gana a preguntar, preguntar gana a permitir, y lo que no coincide con nada cae al valor por defecto del modo. Todo eso es fácil de enunciar y difícil de sostener en la cabeza mientras escribes una docena de reglas. Esto las prueba: pega las reglas, pega los comandos que esperas ejecutar y mira el resultado de cada uno junto a la regla que lo decidió. También encuentra reglas que no pueden activarse nunca, incluidas las de permitir bajo una denegación más amplia.
Características
Cada comando con su resultado y la regla que lo decidió
Denegar sobre preguntar sobre permitir, como lo resuelve el sistema real
Encuentra reglas que no pueden activarse porque otra más amplia las cubre
Detecta una regla de permitir vuelta inalcanzable por una denegación
Informa de líneas que no son reglas en absoluto
Muestra los comandos sin coincidencia en vez de adivinar qué les pasa
Comodines tratados tal cual: sin coincidencia final invisible
Emite el bloque de permisos de settings.json
Cómo usar Probador de reglas de permiso
Pega tus reglas de permitir, preguntar y denegar
Pega los comandos que esperas ejecutar
Lee el resultado de cada uno y qué regla lo decidió
Copia el bloque de permisos en settings.json
Ejemplo
Entrada
Bash(npm run test)
Salida
npm run test:unit — no rule matched
No hay comodín implícito: la regla cubre exactamente ese comando.
Errores comunes y solución de problemas
Mi regla no cubre el comando que esperaba. — No hay comodín final. Bash(npm run test) coincide solo con ese comando; Bash(npm run test:*) cubre las variantes.
Un comando permitido sigue preguntando. — Algo con más precedencia coincidió. Se listan todas las reglas coincidentes de cada comando, en el orden en que se resuelven.
Una de mis reglas aparece como inalcanzable. — Una regla más amplia y de al menos igual precedencia ya cubre todo lo que coincide. Un permitir bajo una denegación amplia es el caso típico: denegar siempre gana, así que el permitir no hace nada.
Una línea aparece como que no es una regla. — Las reglas son Tool o Tool(patrón). Un comando suelto sin prefijo de herramienta no es una regla y se ignora.
Preguntas frecuentes
¿El patrón es un glob o una expresión regular?
Ninguna de las dos exactamente. Es una coincidencia literal con * representando cualquier secuencia de caracteres, aplicada al comando tal como está escrito. La sintaxis de expresiones regulares se trata como texto literal, y por eso una regla con un punto coincide solo con un punto.
¿Qué pasa con un comando que no coincide con ninguna regla?
Cae al comportamiento por defecto del modo de permisos actual, que puede ser preguntar o permitir. Aquí se muestran como sin coincidencia en vez de adivinarlo, porque la respuesta depende del modo y no de las reglas.
¿Cuál gana si coinciden varias?
Denegar, luego preguntar, luego permitir. Se muestran todas las coincidencias de cada comando para que veas qué quedó anulado en lugar de deducirlo.
¿Por qué señala una regla de permitir bajo una de denegar?
Porque ese permitir no puede surtir efecto: denegar siempre gana. La gente las escribe esperando una excepción a una denegación amplia, y no hay ningún error que avise de que no hizo nada.
¿Conviene escribir sobre todo reglas de permitir o de denegar?
Las de denegar son las que se sostienen. Una lista de permitidos hace silencioso el trabajo rutinario; una de denegados es lo que impide justo aquello que nunca quieres que ocurra, y gana sobre todo lo demás.
Herramientas relacionadas
Constructor de hooks — Crea hooks de settings.json y detecta los matchers que nunca se activan.
Constructor de subagentes — Crea el archivo de definición de un subagente con sus herramientas y modelo.
Constructor de comandos — Crea un comando propio, con argumentos y una lista de herramientas.