> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissões e confiança

> Como o Narya pergunta sobre um repositório, como uma regra de permissão é lida, o que a postura de fábrica permite e como auditar cada recusa.

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.

```toml theme={null}
[[rule]]
action = "write"
resource = "/etc/**"
effect = "deny"
```

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.

<Warning>
  Uma execução não interativa transforma cada pergunta em uma recusa registrada. Ela nunca trava. O `narya -p` sempre roda nesse modo.
</Warning>

## 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.