Complementary convention: `agentaccess.txt` — whether agents may access a directory (vs. how to work in it)

Abierto
  • ¿Algo no está bien?
#232 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Área
documentation

Línea de trabajo

Start by reading the linked agentaccess.txt draft and SPEC §11, then review issues #33 and #228 for the related access-policy concerns. This proposal is discussion-only, with no implementation or settled answers; done would require agreement on scope, governance, and the open descendant-policy question.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

AGENTS.md tells agents how to work in a project. I've drafted the complement for the question that comes before it: whether a given agent may operate in a directory at all. agentaccess.txt is a robots.txt-style access policy: per-agent groups, Allow/Disallow paths, evaluated by the harness before anything in the tree is read — including AGENTS.md itself. The files are deliberately disjoint: yours is instructions for the model, so it belongs in context; this one is instructions for the harness, so it must never enter model context — it gates the reading.

Two open issues here already name this gap from opposite sides. #33 asks which paths an otherwise-permitted tool must skip — agentaccess.txt is designed to compose with an ignore file, not replace it: access policy first, path exclusion within granted access second. And #228 lists the properties that make AGENTS.md unsafe as a policy file: chat prompts override it, a nested file displaces the root's rules, and a model reads it. This draft inverts the first and third by construction — enforcement sits in the harness, not the model. The second is genuinely open: whether a descendant file may loosen an ancestor's policy is one of the proposal's open questions, and #228's vendored-code scenario is the sharpest version of that risk.

My proposal presents AGENTS.md as its complement and I want that framing to be fair from your side; and one of its open questions is governance — standalone, or attached to an existing community such as this one (SPEC §11, Q8).

Draft 00, one author, no implementations. If this is out of scope for the tracker, close freely.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
1.9k
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agentsmd/agents.md

Todos los issues de agentsmd/agents.md

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.