Pular para o conteúdo principal
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, um .mcp.json ou um .narya/config.toml. A pergunta nomeia o que chega ao modelo e o que roda nesta máquina. Mova o marcador com as setas e pressione Enter. Enter responde apenas logo depois de uma seta, e letras digitadas não fazem nada. O marcador começa na última resposta. Você tem quatro respostas:
  • load and remember this folder confia nesta pasta.
  • load and remember <parent> and everything under it confia na pasta pai e em tudo abaixo dela. O host calcula a pasta pai, então nenhum cliente pode ampliar o escopo além do que mostrou a você.
  • keep them out é um não duradouro.
  • not this time continua sem confiança. O Narya não guarda nada e pergunta de novo na próxima abertura. esc dá a mesma resposta.
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 decide

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 dentro do diretório seguem livres, e leituras fora dele perguntam. Ações de shell, escrita, rede e ferramenta perguntam. A confiança coloca o conjunto de fábrica no lugar. Com permission_mode = "custom", uma execução única e um diretório confiado rodam o seu permissions.toml em vez disso. A confiança também controla o material do próprio repositório: seus arquivos de instruções, seus hooks de .claude/settings.json, seus servidores de ferramentas de .mcp.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. Uma sessão em um contêiner recebe a confiança desse contêiner. Um contêiner que clonou um repositório conta como confiável, e o contêiner próprio de uma conversa, conversation-<sessionId>, também. Um ambiente nomeado que não clonou nada conta como sem confiança.

​
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, suas regras globais, as regras do projeto e a sessão. A última regra que casa vence. Uma resposta que você lembra vira uma regra: uma global, para todo lugar, ou uma de projeto, para este repositório. Um repositório em que você confia também contribui com regras de projeto pelos blocos [[rule]] do seu .narya/config.toml. Defina permission_mode = "custom" no config.toml para trocar o conjunto de fábrica pelo permissions.toml na sua pasta Narya.

​
A postura de fábrica

Comandos de shell rodam. Chamadas de ferramenta rodam. Leituras dentro do diretório da sessão rodam, e leituras fora dele perguntam. 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 deny network ** desliga. Uma escrita que nomeia uma destas entradas da sua pasta Narya pergunta, a menos que uma regra a negue:
  • o armazenamento, o lock do host e o socket
  • o arquivo de registro do host em execução
  • o diretório de identidade e o organisation.json
Em uma sessão em um contêiner, uma escrita que nomeia o .narya/config.toml do repositório também pergunta. O Narya não lembra nenhuma resposta a essas perguntas, e uma execução não assistida as recusa. A ferramenta de leitura recusa arquivos .env, como prod.env e .env.local, e lê o .env.example dentro do diretório. Essas regras governam apenas a ferramenta de leitura. Um grep do diretório devolve o conteúdo deles. Um comando de shell os lê sob as regras de shell. Uma escrita em um deles é 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. As regras de shell julgam a ferramenta de terminal uma vez, quando ela abre, pelo programa que ela inicia. Nenhuma regra lê o que o modelo digita em um terminal aberto. deny tool terminal remove o terminal.
Uma execução não interativa não pode esperar que uma pessoa responda a uma pergunta de permissão. O narya -p roda nesse modo. Os registros de recusa com escopo de sessão têm os limites de auditoria abaixo. Para deixar uma execução fazer ações nomeadas sem perguntar, passe --allow. Veja Automação e CI.

​
Quando uma mudança de configuração vale

Na sua própria máquina, uma nova versão do config.toml, do permissions.toml, do .narya/config.toml de um repositório confiado ou da seção de hooks de um settings.json do Claude Code só vale depois que uma pessoa a permite em uma conversa acompanhada. Isso vale para quem quer que tenha mudado o arquivo. Até lá, a última versão permitida continua valendo. Execuções únicas, agendamentos e sessões desacompanhadas nunca perguntam, então mantêm a última versão permitida. O próximo turno acompanhado pergunta uma vez por arquivo alterado e mostra o que mudou. Um não mantém a versão que vale até o arquivo mudar de novo. A primeira versão de cada arquivo que o Narya lê não precisa de um sim. Um config.toml que você adiciona a uma pasta que rodou sem ele é uma nova versão. Um sim ao config.toml vale na hora para os modelos e, a partir da sua próxima mensagem, para o modelo padrão. Todos os outros ajustes nele valem no próximo início do host, como [spend] daily_ceiling_usd e [schedules] ceiling_usd. Um sim ao permissions.toml também vale no próximo início do host. Quando você confia em uma pasta pai, o primeiro repositório abaixo dela carrega os próprios arquivos com essa resposta. Outro repositório abaixo dessa pasta pergunta uma vez antes que o seu .narya/config.toml, os seus hooks ou os seus servidores de .mcp.json passem a valer.

​
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 entregar uma sessão ao host como desacompanhada. Uma segunda execução não muda nada. O host recusa isso em um diretório em que ninguém confia. 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.