Regras de permissão parecem globs e se comportam como algo mais estreito, e é aí que começa o problema. Uma regra é comparada com o comando como escrito, e não há curinga final implícito: uma regra que cobre um comando de teste não cobre o mesmo comando com uma flag no fim. Negar vence perguntar, perguntar vence permitir, e o que não casa com nada cai no padrão do modo. Tudo isso é fácil de enunciar e difícil de segurar na cabeça enquanto se escreve uma dúzia de regras. Isto as testa: cole as regras, cole os comandos que espera rodar e veja o resultado de cada um ao lado da regra que decidiu. Também encontra regras que nunca podem disparar, inclusive as de permitir sob uma negação mais ampla.
Recursos
Cada comando com seu resultado e a regra que decidiu
Negar sobre perguntar sobre permitir, como o resolvedor real faz
Encontra regras que nunca disparam porque outra mais ampla as cobre
Detecta uma regra de permitir tornada inalcançável por uma de negar
Relata linhas que não são regras
Mostra comandos sem correspondência em vez de adivinhar o que acontece
Curingas tratados como escritos — sem casamento final invisível
Emite o bloco de permissões do settings.json
Como usar Testador de regras de permissão
Cole suas regras de permitir, perguntar e negar
Cole os comandos que espera rodar
Leia o resultado de cada um e qual regra decidiu
Copie o bloco de permissões para o settings.json
Exemplo
Entrada
Bash(npm run test)
Saída
npm run test:unit — no rule matched
Não há curinga implícito: a regra cobre exatamente aquele comando.
Erros comuns e solução de problemas
Minha regra não cobre o comando que eu esperava. — Não há curinga final. Bash(npm run test) casa só com aquele comando; Bash(npm run test:*) cobre as variações.
Um comando permitido ainda pergunta. — Algo com precedência maior casou. Todas as regras que casam com cada comando são listadas, na ordem em que são resolvidas.
Uma das minhas regras aparece como inalcançável. — Uma regra mais ampla e de precedência ao menos igual já cobre tudo o que ela casa. Um permitir sob uma negação ampla é o caso típico: negar sempre vence, então o permitir não faz nada.
Uma linha é relatada como não sendo uma regra. — Regras são Tool ou Tool(padrão). Um comando solto sem prefixo de ferramenta não é uma regra e é ignorado.
Perguntas frequentes
O padrão é um glob ou uma expressão regular?
Nenhum dos dois exatamente. É uma correspondência literal com * representando qualquer sequência de caracteres, aplicada ao comando como escrito. Sintaxe de expressão regular é tratada como texto literal, e por isso uma regra com ponto casa só com um ponto.
O que acontece com um comando que não casa com regra nenhuma?
Ele cai no comportamento padrão do modo de permissões atual, que pode ser perguntar ou permitir. Aqui eles aparecem como sem correspondência em vez de adivinhados, porque a resposta depende do modo e não das regras.
Qual vence quando várias casam?
Negar, depois perguntar, depois permitir. Todas as correspondências de cada comando são mostradas para você ver o que foi sobreposto em vez de deduzir.
Por que aponta uma regra de permitir sob uma de negar?
Porque aquele permitir nunca pode ter efeito: negar sempre vence. As pessoas escrevem isso esperando uma exceção a uma negação ampla, e não há erro algum avisando que não fez nada.
Devo escrever mais regras de permitir ou de negar?
As de negar são as que se sustentam. Uma lista de permitidos deixa o trabalho de rotina silencioso; uma de negados é o que impede justamente o que você nunca quer que aconteça, e vence tudo o mais.
Ferramentas relacionadas
Construtor de hooks — Monte hooks do settings.json e pegue os matchers que nunca disparam.
Construtor de subagentes — Monte o arquivo de definição de um subagente com ferramentas e modelo.
Construtor de comandos — Crie um comando próprio, com argumentos e uma lista de ferramentas.