The repository you cloned is also a settings file

Somebody sends you a folder. A starter template for the kind of app you want. A client's codebase, so you can add the one report they keep asking for. A project a contractor finished eight months ago and nobody has touched since. You put it on your machine, open a terminal in it, and start your coding agent.

Between that moment and your first typed word, the folder gets to talk.

That has been true for a while, and two changes in the last seven days made it worth writing down. On September 18, Claude Code 2.1.277 added AGENTS.md support: "in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead." On September 23, version 2.1.281 extended that to Amazon Bedrock, Google Vertex AI, Microsoft Foundry, LLM gateways and sessions with telemetry turned off. And on September 24, version 2.1.282 shipped a cluster of changes about which settings a repository on your disk is allowed to apply to your session, and which ones it is now ignored for.

Read together, the week says one thing. The directory is an input. Treat it like one.

What loads before you type

Start with the mild end, because it is the part that just got bigger.

An AGENTS.md file is project instructions in plain English: build commands, conventions, "always do this, never do that." It is the filename several coding tools converged on, which is the whole point of the change. The documentation says it plainly: Claude Code can read AGENTS.md as your project instructions "so a repository already set up for other coding agents works without adding a CLAUDE.md, an import, or a setting."

The rule for when it loads is narrow and worth memorizing, because it is the difference between a file that runs your session and a file that sits there:

• You have an AGENTS.md and no CLAUDE.md or CLAUDE.local.md in your working directory or above it, and Claude reads the AGENTS.md.
• You have both, and Claude reads your CLAUDE.md files only.
• Your CLAUDE.md already imports AGENTS.md, and you get both through the import.

Your own ~/.claude/CLAUDE.md and your organization's managed one do not count for that check, so they keep loading alongside. In an interactive session you get a line in the conversation that says so, something like no CLAUDE.md found; AGENTS.md loaded: /home/you/repo/AGENTS.md. That line is the only notice you get, and it scrolls.

Here is the honest limit on how much this matters. Instructions are not permissions. The same documentation is blunt about it: Claude "treats them as context, not enforced configuration," and if you want to block an action regardless of what the model decides, you use a hook, not a markdown file. A hostile AGENTS.md can push a model toward a bad idea. It cannot grant anything.

The things that can grant something live one directory over, in .claude/.

Whose settings win

There are five places a setting can come from, and the order is fixed. Highest first:

1. Managed settings, deployed by your organization through a managed-settings.json file, an MDM policy, or the claude.ai console. Nothing you set overrides them.
2. Command line, what you pass with claude --settings for this session.
3. Project local, .claude/settings.local.json, your personal settings for this one project.
4. Shared project, .claude/settings.json, which is committed and which everyone who clones the repository gets.
5. User, ~/.claude/settings.json, you in every project.

Look at four and five. The repository's committed settings file sits above your own personal one. That is deliberate and mostly sensible, because it is how a team makes sure everyone gets the same hooks and the same permissions without each person configuring it by hand. It is also the sentence a lot of people have never read.

The documentation spells out the consequence in the section on running an agent in a repository you did not write. If you want hooks off for a run, you pass --settings '{"disableAllHooks": true}', and the docs add: "Setting it in your user settings alone isn't enough, because the repository's project settings take precedence over yours and can set it back to false."

Your preference loses to the folder's preference. In a repository you wrote, that is a feature. In a repository somebody handed you, it is a thing to know.

What the trust prompt actually covers

Most people have seen the workspace trust dialog and pressed Enter on it. It is worth knowing what that press does, because it does less than the name suggests, and the gap is not obvious.

What waits for trust: permissions.allow rules and permissions.additionalDirectories from the project's .claude/settings.json. These grant capability, so the dialog lists them and holds them until you accept. deny and ask rules are not affected, because they only restrict, and a restriction is safe to apply immediately.

What does not wait for trust, in the case where you trusted a parent folder rather than this one: hooks in the project's settings files, the env block, helper commands such as apiKeyHelper, and a project skill's pre-approved tools. The documentation's own line on that last one is unambiguous. "Workspace trust never gates a skill's allowed-tools in any session."

And in a non-interactive run, claude -p or an SDK session, there is no dialog at all. The docs note that servers declared in the project's .mcp.json are "connected without asking, approved or not," and that skipped allow rules produce a warning on stderr, which nobody reads in a script.

None of that is a scandal. It is a design with a shape, and the shape is: instructions and side-channel configuration load early and broadly, while capability grants wait for a human. Knowing which bucket a thing is in tells you what the dialog bought you.

The part that got tighter this week

Against that backdrop, the September 22 to 24 releases read as one project. Working from the changelog:

Where a write lands is now what gets approved. Version 2.1.280, September 22, fixed "writes through a symlinked path being judged by their in-tree spelling: the prompt names where the write lands, and acceptEdits, allow rules and auto mode no longer approve one landing outside." A symlink inside a project that points somewhere else on your disk used to be judged by the path as written. If you have ever approved a write because the path looked like it was inside your project, that is the case this closes.

A repository can no longer pre-approve its own tools under a locked policy. Version 2.1.282, September 24, fixed "repository, user and --add-dir skills, commands and skills-directory plugin manifests pre-approving their own tools via allowed-tools under managed allowManagedPermissionRulesOnly." When an administrator has said that only managed permission rules apply, a skill shipped in the repository no longer gets to write its own exception.

A project can no longer change where your session telemetry goes. Also on the 24th: project and local settings now "ignore OpenTelemetry variables that turn on export, set its endpoint, or capture content," naming CLAUDE_CODE_ENABLE_TELEMETRY and OTEL_LOG_*. A repository could previously set those through its settings env block. Paired with it is a new startup notice, plus entries in /status and claude doctor, "listing telemetry variables in a project's settings files that were ignored or that turned telemetry off." That second half is the better half. You now get told when a folder tried.

A project cannot unsandbox a command under a strict policy. sandbox.excludedCommands entries from project and local settings are now ignored when managed settings or --settings set allowUnsandboxedCommands: false, or managed allowManagedDomainsOnly: true.

Bad administrator config now fails safe. Two fixes in the same release: a mistyped value for a boolean lock key such as allowManagedPermissionRulesOnly now applies anyway and startup names the key, and a managed permissions, autoMode, worktree or attribution block is no longer discarded wholesale because one nested value was invalid. On Windows and WSL, a managed policy that is present but unreadable now stops user-writable settings from applying rather than quietly handing control back.

Background sessions ask first. Version 2.1.281 fixed claude --bg "starting a background session, and running its project hooks, in a directory that had not passed the workspace trust prompt." It now asks, or exits when it cannot.

Restrictions follow the sessions you spawn. The same release fixed --setting-sources and the SDK's settingSources not being forwarded to spawned sessions, so teammates, /bg, claude agents sessions and worktree sessions now start with the parent's restriction instead of a fresh, unrestricted one.

Name squatting closed. Plugin marketplaces whose name imitates a reserved marketplace name are now refused, and skill folders, command files and MCP servers using the anthropic-skills or claude-ai namespace no longer load or list under those names.

Eight changes, three days, one direction. Every one of them moves a decision away from a file that arrived with the folder.

What to do with a folder you did not write

The documentation has a short list for exactly this, under the heading about running an agent in a repository you did not write. These are worth keeping somewhere you can find them:

• `--setting-sources user`, or the SDK's settingSources without project settings, so the agent reads neither the project's settings files nor its .mcp.json.
• `--bare`, so it reads no hooks, skills, custom commands, subagents, plugins or .mcp.json servers from the project. Note the exception the docs give: the project's env block and helpers such as awsAuthRefresh still apply.
• `--settings '{"disableAllHooks": true}'` for the run, remembering that setting it in your user file alone will not hold.
• `disabledMcpjsonServers`, to reject a named .mcp.json server in every session type.

And before any of that, a sixty-second look that needs no flags. List .claude/ and see whether there is a settings.json in it. Open AGENTS.md or CLAUDE.md and actually read it, the way you would read a script before running it. Check whether there is a .mcp.json, and if there is, look at what it connects to. Search the settings file for hooks. And when the trust dialog comes up, read the rules it lists instead of pressing Enter, because listing them is the entire job that dialog does.

If the folder came from a client, one more: ask who last touched the .claude/ directory. It is a reasonable question and the answer is usually "nobody, that came with the template," which is itself useful information.

The fair case against making a fuss

Most repositories are fine. The overwhelming majority of AGENTS.md files are somebody writing down the build command so the next person does not have to guess, and the overwhelming majority of .claude/settings.json files are a team agreeing on four allow rules. Treating every cloned folder as hostile would cost you more than it saves, and it would throw away the thing that makes shared configuration worth having, which is that a good repository can hand you a working setup in one step.

It is also worth being honest about who this week's fixes help. Most of them tighten what a repository can do _under a managed policy_ — an administrator's settings file, an MDM profile, a console. If you are one person building on your own laptop, you have no managed tier, and several of these changes do nothing for you at all. What you get instead is the startup notice, the write path named where it actually lands, and a trust prompt that now also covers background sessions. That is real, and it is smaller.

The thing that does not shrink is the precedence order. A repository's committed settings still outrank your personal ones, by design, in every session where you let it read them. The remedy is not distrust. It is a look, and four flags you now know the names of.

Before you point an agent at a folder somebody else wrote, decide what that folder may run on your machine. That decision used to be implicit. As of this week, at least the tool will tell you a little more about what you decided.