1

Sobre o 1, tem um caso parecido que pega bastante gente: o hook que nem consegue rodar. Se o script não existe, falta o jq na máquina ou estoura o timeout, por padrão isso também vira erro não bloqueante e a ação passa. Dá pra colocar "onFailure": "block" no hook, aí falha e timeout num PreToolUse bloqueiam igual ao exit 2.

E no 2, a regra Read(./.env) pega um pouco mais do que as ferramentas de arquivo. A doc de permissões diz que ela também vale pra cat, head, tail e redirecionamento no Bash. O que escapa é um grep -r rodado na pasta e script que abre o arquivo por conta própria, como você falou, e pra esses só o sandbox resolve.

Carregando publicação patrocinada...
1

Ótimo complemento, obrigado! Os dois pontos batem com a documentação:

  • "onFailure": "block": nas versões recentes (a doc cita a 2.1.295 ou mais nova), faz a falha do hook bloquear a ação. Vale muito em hook de política, justamente para script ausente, dependência faltando ou timeout não deixarem passar. Só confira a versão antes, porque em versão antiga o campo não existe.
  • Read(./.env) no deny: sim, a página de permissões diz que ele também pega cat, head, tail e redirecionamento no Bash. O que escapa é grep -r e script que abre o arquivo por conta própria. Para esses, sandbox, e o segredo fora do repositório.
1

verdade, a ressalva da versão é importante. em versão antiga o campo provavelmente só é ignorado sem erro nenhum, aí a pessoa acha que tá protegida e não tá.