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

[ppseprus]

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.

[Pjrich1313]

I have done this without no luck, I had been stopped at all times. I know how the bots work. Automatically, right so again what's the issue with this. I tooled them in. Every time I do some comes along and tried to protest the flow so how do we stop the truth. I know it's not a tool we can employ in. So how do make the truth known. That's what I need answers too. Thank you but I need the answers for this. If we could do this then we'll can finally get paid until then, I'm in limbo.

[daichunghy]

The placement question this raises for me: an access policy that lives inside the tree it governs inherits the nearest-file-wins problem from #228 — a contributed or vendored agentaccess.txt could grant access to its own subtree before anyone reviews it.

The rule I use for the equivalent case in PatchGate: governance inputs are read from the pull request's base revision, never from the revision a PR proposes. The same read would fit here — the harness evaluates agentaccess.txt from the trusted tree, not the one being contributed.

[ppseprus]

You've landed on what the spec tracks as its open question Q3 (https://agentaccesstxt.org/SPEC.html#11-open-questions-for-discussion).

Just a correction: agentaccess.txt is restriction-only, so a file arriving in a PR or a vendored subtree can't grant anything — enforcement composes by intersection with the tool's own permission system (§7), and a conforming agent is barred from writing a nearer agentaccess.txt itself, so the file can't be planted by the agent it governs. What such a file can do, exactly as you describe, is void an ancestor's restriction for its own subtree: under nearest-file discovery (§4) a new deep file with Allow: / replaces a stricter root file outright, and a new file deep in a tree draws far less review attention than a diff to a root policy. The spec names that gap (§9) and Q3 asks what to do about it.

I agree that your base-revision rule is the same shape as GitHub's own CODEOWNERS handling — a PR that modifies CODEOWNERS is evaluated against the base branch, so the change can't approve itself. For review and CI agents that's the natural fix, and it's on the table for the next draft.

One scoping note, because the PR frame covers only part of the ground: agentaccess.txt is a filesystem convention, not a repository one. The enforcement point sees directories and files, not branches and revisions — discovery walks the directory tree (§4) and the check happens at the harness's file-access layer (§7). A governed tree may be a home directory or a shared drive that never sees version control, and even in a repo, checkout has already collapsed base and proposed into the one tree on disk. Base-revision evaluation is the right answer where the evaluator holds both revisions, as yours does in review; for every other tree, Q3's other candidate is intersection composition (a descendant file can tighten an ancestor's policy but never loosen it), which needs only the filesystem.
There's an open thread on exactly this question: agentaccesstxt/agentaccess.txt#3 — PatchGate's base-revision practice would be a genuinely useful data point there.

[daichunghy]

That answers it. I'll treat a contributed agentaccess.txt as able to void an ancestor restriction, not as able to grant access.

For review and CI I keep reading the file from the base revision. For a tree that is only a filesystem, intersection composition is the other candidate; I leave Q3 open.