La pregunta de confianza
El cliente pregunta ¿Confiar en este repositorio? una ida y vuelta después de abrirse. Pregunta solo cuando el directorio lleva algo gobernado: un archivo de instrucciones, un directorio de recursos, un
.mcp.json o un .narya/config.toml.
La pregunta nombra qué llega al modelo y qué se ejecuta en esta máquina.
Mueve el marcador con las flechas y presiona Enter. Enter responde solo justo después de una flecha, y las letras que escribes no hacen nada. El marcador empieza en la última respuesta. Tienes cuatro respuestas:
load and remember this folderconfía en esta carpeta.load and remember <parent> and everything under itconfía en la carpeta padre y en todo lo que hay bajo ella. El host calcula la carpeta padre, así que ningún cliente puede ampliar el alcance más allá de lo que te mostró.keep them outes un no duradero.not this timecontinúa sin confianza. Narya no guarda nada y vuelve a preguntar en el siguiente inicio.escda la misma respuesta.
/trust para reabrir la pregunta.
Qué decide la confianza
La confianza decide qué conjunto de reglas se ejecuta. Un directorio en el que nadie confía se ejecuta bajo un conjunto más estricto, y solo donde una persona puede responder. Una ejecución de un solo turno mantiene el conjunto de fábrica. Las lecturas dentro del directorio siguen libres, y las lecturas fuera de él preguntan. Las acciones de shell, de escritura, de red y de herramienta preguntan. La confianza pone en su lugar el conjunto de fábrica. Con
permission_mode = "custom", una ejecución de un solo turno y un directorio de confianza ejecutan tu permissions.toml en su lugar.
La confianza también controla el material propio del repositorio: sus archivos de instrucciones, sus hooks de .claude/settings.json, sus servidores de herramientas de .mcp.json y sus comandos, skills y agentes de .claude y .narya. Narya lo ignora todo en un repositorio sin confianza, en cualquier modo.
Una sesión en un contenedor toma la confianza de ese contenedor. Un contenedor que clonó un repositorio cuenta como de confianza, y también el contenedor propio de una conversación, conversation-<sessionId>. Un entorno con nombre que no clonó nada cuenta como sin confianza.
Cómo se lee una regla
Una regla es una tabla TOML con tres claves.
shell, read, write, network y tool. La acción decide qué compara Narya. Un glob de ruta corresponde a read y write. El texto del comando corresponde a shell, después de que Narya descompone la línea en los comandos que realmente ejecuta. Un host corresponde a network. Un nombre de herramienta corresponde a tool.
Existen tres efectos: allow, ask y deny.
No hay campo de orden. La posición en el archivo es la precedencia. Narya concatena cuatro ámbitos en este orden: su conjunto de fábrica, tus reglas globales, las reglas del proyecto y la sesión. Gana la última coincidencia.
Una respuesta que recuerdas se convierte en una regla: una global, para todas partes, o una de proyecto, para este repositorio. Un repositorio en el que confías también aporta reglas de proyecto a través de los bloques [[rule]] de su .narya/config.toml. Define permission_mode = "custom" en config.toml para reemplazar el conjunto de fábrica por permissions.toml en tu home de Narya.
La postura de fábrica
Los comandos de shell se ejecutan. Las llamadas a herramientas se ejecutan. Las lecturas dentro del directorio de la sesión se ejecutan, y las lecturas fuera de él preguntan. Más de cuarenta reglas de shell preguntan primero, entre ellas
rm -r, sudo, git push --force, chmod, dd y kill -9. Las escrituras dentro del repositorio se ejecutan, y las escrituras fuera de él preguntan. Las acciones de red preguntan, excepto la búsqueda web del propio proveedor, que deny network ** desactiva.
Una escritura que nombra una de estas entradas de tu home de Narya pregunta, a menos que una regla la niegue:
- el almacén, el lock del host y el socket
- el archivo de registro del host en ejecución
- el directorio de identidad y
organisation.json
.narya/config.toml del repositorio también pregunta. Narya no recuerda ninguna respuesta a estas preguntas, y una ejecución desatendida las rechaza.
La herramienta de lectura rechaza los archivos .env, como prod.env y .env.local, y lee .env.example dentro del directorio. Estas reglas gobiernan solo la herramienta de lectura. Un grep del directorio devuelve su contenido. Un comando de shell los lee bajo las reglas de shell. Una escritura sobre uno de ellos está permitida.
Narya juzga una línea de shell con el veredicto más estricto de todo lo que realmente ejecuta. Una línea que Narya no puede analizar pregunta, y Narya no recuerda nada de ella.
Las reglas de shell juzgan la herramienta de terminal una vez, cuando se abre, por el programa que inicia. Ninguna regla lee lo que el modelo escribe en una terminal abierta. deny tool terminal elimina la terminal.
Cuándo entra en vigor un cambio de configuración
En tu propia máquina, una nueva versión de
config.toml, de permissions.toml, del .narya/config.toml de un repositorio de confianza o de la sección de hooks de un settings.json de Claude Code entra en vigor solo después de que una persona la permite en una conversación atendida. Esto vale sin importar quién cambió el archivo. Hasta entonces, la última versión permitida sigue en vigor. Las ejecuciones de un solo turno, las programaciones y las sesiones desatendidas nunca preguntan, así que mantienen la última versión permitida.
El siguiente turno atendido pregunta una vez por cada archivo cambiado y muestra qué cambió. Un no mantiene la versión en vigor hasta que el archivo vuelva a cambiar. La primera versión de cada archivo que Narya lee no necesita un sí. Un config.toml que agregas a un home que se ejecutó sin él es una nueva versión.
Un sí a config.toml se aplica de inmediato a los modelos y, desde tu siguiente mensaje, al modelo predeterminado. Todos los demás ajustes en él entran en vigor en el siguiente inicio del host, como [spend] daily_ceiling_usd y [schedules] ceiling_usd. Un sí a permissions.toml también entra en vigor en el siguiente inicio del host.
Cuando confías en una carpeta padre, el primer repositorio debajo de ella carga sus propios archivos con esa respuesta. Otro repositorio debajo de esa carpeta pregunta una vez antes de que su .narya/config.toml, sus hooks o sus servidores de .mcp.json entren en vigor.
Auditoría
Narya escribe una fila por cada pregunta y por cada rechazo que pertenece a una sesión, incluidos los rechazos que no llegaron a ninguna persona. Un rechazo fuera de una sesión, o una fila que el almacén no logra escribir, no deja fila. El rechazo sigue en pie. Cada fila lleva:
- la acción y el recurso
- qué reglas coincidieron, y qué otorgaría un permiso recordado
- el estado y quién decidió
- el motivo
- el alcance de la respuesta
narya permissions denied. Agrega --session <id>, --since <time> o --until <time> para acotar el rango. Una página contiene 100 filas, y Narya lo indica cuando trunca.
La retención es opcional por clase y conserva todo de forma predeterminada. El ajuste [retention] permission_asks barre las filas ya decididas y conserva las pendientes.
Sesiones atendidas y desatendidas
Cada sesión registra una postura,
attended o detached. Una sesión desatendida rechaza y registra la siguiente pregunta en lugar de bloquearse para siempre. Ejecuta narya session promote <session-id> para entregar una sesión al host como desatendida. Una segunda ejecución no cambia nada. El host lo rechaza en un directorio en el que nadie confía.
Una sesión registrada como desatendida en un directorio en el que nadie confía vuelve a atendida en su siguiente comprobación de control. La lectura de confianza falla en cerrado.