Skip to main content
O Narya verifica um portão antes de cada chamada de ferramenta. Duas coisas decidem a resposta: se você confia no diretório e o que as regras dizem.

​
A pergunta de confiança

O cliente pergunta Confiar neste repositório? uma ida e volta depois de abrir. Ele pergunta apenas quando o diretório traz algo governado: um arquivo de instruções, um diretório de recursos ou um .narya/config.toml. A pergunta mostra duas linhas de divulgação: o que chega ao modelo e o que roda nesta máquina. Você tem quatro respostas:
  • y confia nesta pasta.
  • p confia nesta pasta e na pasta pai dela. O host calcula a pasta pai, então nenhum cliente pode ampliar o escopo além do que mostrou a você.
  • n é um não duradouro.
  • esc continua sem confiança. O Narya não guarda nada e pergunta de novo na próxima abertura.
O Narya guarda uma linha por caminho canônico. Uma consulta sobe pela árvore, e o ancestral confiado ou recusado mais próximo decide. Digite /trust para reabrir a pergunta.

​
O que a confiança libera

A confiança decide qual conjunto de regras roda. Um diretório em que ninguém confia roda sob um conjunto mais restrito, e apenas onde uma pessoa pode responder. Uma execução única mantém o conjunto de fábrica. Leituras seguem livres. Ações de shell, escrita, rede e ferramenta perguntam. A confiança coloca o conjunto de fábrica no lugar. A confiança também controla o material do próprio repositório: seus arquivos de instruções, seus hooks de .claude/settings.json e seus comandos, skills e agentes em .claude e .narya. O Narya ignora tudo isso em um repositório sem confiança, em qualquer modo.

​
Como uma regra é lida

Uma regra é uma tabela TOML com três chaves.
Existem cinco ações, e nada além delas: shell, read, write, network e tool. A ação decide o que o Narya compara. Um glob de caminho compara read e write. O texto do comando compara shell, depois que o Narya decompõe a linha nos comandos que ela de fato roda. Um host compara network. Um nome de ferramenta compara tool. Existem três efeitos: allow, ask e deny. Não existe campo de ordem. A posição no arquivo é a precedência. O Narya concatena quatro escopos nesta ordem: seu conjunto de fábrica, seu arquivo global, o arquivo do projeto e a sessão. A última regra que casa vence. O Narya lê o permissions.toml na sua pasta Narya apenas quando o config.toml define permission_mode = "custom". Um repositório em que você confia contribui com blocos [[rule]] pelo seu .narya/config.toml.

​
A postura de fábrica

Comandos de shell rodam. Chamadas de ferramenta rodam. Mais de quarenta regras de shell perguntam antes, entre elas rm -r, sudo, git push --force, chmod, dd e kill -9. Escritas dentro do repositório rodam, e escritas fora dele perguntam. Ações de rede perguntam, exceto a busca na web do próprio fornecedor, que apenas deny network ** desliga. A ferramenta de leitura recusa um arquivo .env e lê todo o resto. Essa regra governa apenas a ferramenta de leitura. Um grep do diretório devolve o conteúdo do arquivo. Um comando de shell o lê sob as regras de shell. Uma escrita nele é permitida. O Narya julga uma linha de shell pelo veredito mais restrito entre tudo o que ela de fato roda. Uma linha que o Narya não consegue analisar pergunta, e o Narya não guarda nada dela.
Uma execução não interativa transforma cada pergunta em uma recusa registrada. Ela nunca trava. O narya -p sempre roda nesse modo.

​
Auditoria

O Narya grava uma linha por pergunta e por recusa que pertence a uma sessão, incluindo recusas que não chegaram a nenhuma pessoa. Uma recusa fora de uma sessão, ou uma linha que o armazenamento não consegue gravar, não deixa linha. A recusa continua valendo. Cada linha traz:
  • a ação e o recurso
  • quais regras casaram e o que um allow lembrado concederia
  • o status e quem decidiu
  • o motivo
  • o escopo da resposta
Allows derivados de regra não trazem linha. Leia as linhas de volta com narya permissions denied. Adicione --session <id>, --since <time> ou --until <time> para estreitar o intervalo. Uma página comporta 100 linhas, e o Narya avisa quando corta. A retenção é opcional por classe e guarda tudo por padrão. O ajuste [retention] permission_asks varre as linhas decididas e mantém as pendentes.

​
Sessões acompanhadas e desacompanhadas

Cada sessão registra uma postura, attended ou detached. Uma sessão desacompanhada recusa e registra a próxima pergunta em vez de travar para sempre. Rode narya session promote <session-id> para marcar uma sessão como acompanhada. Isso repete a pergunta de saída do cliente, e uma segunda execução não muda nada. Uma sessão registrada como desacompanhada em um diretório em que ninguém confia volta para acompanhada na próxima verificação de portão. A leitura de confiança falha fechando.