What Does That Repo Tell Your Agent to Do?

You review the code you clone. Almost nobody reviews the part of it addressed to the agent. A checkout can carry instruction files the model treats as orders, shell commands wired to fire on agent events, MCP servers it asks you to launch, and skills it hands your assistant — and none of that reads like code, so it gets skimmed. This is the inventory to take before you point an agent at somebody else's repository, and the commands to take it with.

The blind spot is a habit, not a vulnerability

git diff shows you code, and you read code carefully because you know what a subtle bug looks like. The same diff shows you three added lines in a CLAUDE.md, and you skim them, because they are prose and prose looks like documentation.

They are not documentation. They are instructions your model will follow, in the same context window as your own instructions, with no visual distinction between the two. That is the entire problem in one sentence, and it is a review-culture gap rather than a bug in any particular tool.

Prose in a repository used to be a suggestion to a human. It is now an input to something that acts.

The surface is bigger than you picture

Four categories, in rough order of how much they can do:

1. Instruction files, including the nested ones

CLAUDE.md, AGENTS.md, .cursorrules and friends get loaded and treated as instructions. The root one you will probably notice. The ones several directories deep — which apply when the agent happens to be working in that subdirectory — are the ones that slip through, because nothing surfaces them until they are already active.

Scale check: run an inventory against a checkout of langfuse/langfuse — an ordinary, reputable open-source project, picked precisely because there is nothing wrong with it — and you get twelve instruction files, about 5,593 lines and roughly 42,000 estimated tokens of material your agent is told to follow. Eleven of the twelve are not at the repo root. That is not an accusation about langfuse. It is the normal size of a thing nobody is reading.

2. Hook commands

Hooks are shell commands wired to agent lifecycle events — session start, prompt submit, before or after a tool call. They are the most powerful item on this list by a wide margin, because a hook is not a suggestion to a model that may or may not comply. It is a command that runs.

Clients differ in how much they gate this, and the mainstream ones prompt you to trust a directory before project settings take effect. A trust prompt is a click, and clicks get clicked — especially the fifth time that day. Treat repo-supplied hooks the way you treat a Makefile target you are about to run as yourself, because that is what they are.

3. Declared MCP servers

A .mcp.json asks your client to launch servers when you work in that project. The detail worth pausing on is the launch command, which is very often of the form npx -y some-package. That fetches and executes the current published version at start time. The code that runs is downloaded when you launch, and it is not the code you reviewed.An unpinned dependency is a supply chain, and this is a supply chain with a direct line into your agent's tool list.

4. Skills, commands, and subagents shipped by the repo

.claude/skills, .claude/commands, .claude/agents — capability the repository hands your assistant. Mostly benign and often genuinely useful. Worth knowing about, because every one of them also carries an always-loaded description into your context window, which is its own slow tax: why your context window is half spent before you type.

What can actually go wrong (calibrated)

The realistic risks are not a movie plot. In rough order of likelihood:

• Instruction collision, no malice.Overwhelmingly the common case. The repo's conventions contradict yours — a different commit format, a rule to never touch some directory, a demand that all output be in a house style — and your agent quietly obeys the repo instead of you. Nothing was attacked. Your afternoon was still wasted.
• Context dilution.Forty thousand tokens of somebody else's conventions crowding out your task. The agent gets worse at your work and nobody can say why.
• Prompt injection through prose. An instruction file, or a comment in a file the agent reads, that tells the model to do something you did not ask for — exfiltrate an env var, add a dependency, weaken a check. This is the headline risk, and it is real, but it is rarer than the first two and it needs the model to have a capability worth abusing.
• Direct execution via hooks or an unpinned server.Lowest likelihood, highest impact, and the only one where the model's judgment is not in the loop at all.

The audit, in commands

Run this before the first agent session in a checkout you did not write. It takes under a minute.

# 1. every instruction file, including nested ones
$ find . \( -name 'CLAUDE.md' -o -name 'AGENTS.md' -o -name '.cursorrules' \
        -o -name 'copilot-instructions.md' \) \
        -not -path '*/node_modules/*' -not -path '*/.git/*'

# 2. how much material is that, really?
$ find . -name 'CLAUDE.md' -o -name 'AGENTS.md' | xargs wc -l | tail -1

# 3. shell wired to agent events
$ cat .claude/settings.json 2>/dev/null | jq '.hooks'

# 4. servers the repo wants launched — read every command line
$ cat .mcp.json 2>/dev/null | jq '.mcpServers'

# 5. capability the repo ships to your agent
$ ls .claude/skills .claude/commands .claude/agents 2>/dev/null

Two refinements that matter more than they look. First, symlinks: repos commonly expose the same file under several names (AGENTS.md and .agents/AGENTS.md and CLAUDE.md all pointing at one document), so count once and read once instead of panicking at a large number. Second, this is a per-update problem, not just a per-clone problem — which is why the next section matters more than this one.

Put it in code review, where it belongs

The clone-time audit is the easy half. The dangerous change is the one that arrives in a pull request six months later, in a repo you already trust, in a three-line diff nobody reads because it is “just docs.”

# what changed in the part addressed to the agent?
$ git diff main...HEAD -- '**/CLAUDE.md' '**/AGENTS.md' '.cursorrules' \
      '.claude/**' '.mcp.json'

# and before you pull an update to a dependency you agent-operate in
$ git log --oneline -- '.claude/settings.json' '.mcp.json' | head

Add those paths to a CODEOWNERS entry so the review is forced rather than remembered. The mental model to adopt: treat .claude/ and .mcp.json exactly like your CI configuration.Both are files in the repo that cause commands to run on someone's machine. Nobody merges a workflow change without reading it. Same bar.

A policy that survives contact with a deadline

1. 1Inventory before the first session. One command block, under a minute, in a checkout you did not write. If the output is empty, you are done and you know it — that is worth the minute by itself.
2. 2Read every hook command and every server launch line. These are the two categories that execute. Everything else merely persuades. If you read nothing else, read these.
3. 3Pin what you accept. If you allow a repo-declared MCP server, pin the version (npx -y pkg@1.4.2) instead of floating on latest. Same instinct as a lockfile, same reason.
4. 4First pass read-only. For an unfamiliar repo, run the agent without write or execute permissions until you know what is in it. Unreviewed instructions are much less interesting to an agent that cannot act on them.
5. 5Gate the surface in review, forever. CODEOWNERS on the agent paths, and a habit of diffing them on every dependency bump. This is the step that still works in month nine.

Steps 1 and 2 are the ones we automated, because a manual inventory is exactly the kind of discipline that survives two weeks. whats-inherited-mcp is free and MIT: it enumerates instruction files (with symlink dedup and a nested-file warning), hook commands, MCP servers the repo declares, and shipped skills and subagents, and hands the summary to the agent as structured output.

$ claude mcp add --scope user whats-inherited -- npx -y whats-inherited-mcp

Honest limits

An inventory is not a verdict. Knowing there are twelve instruction files does not tell you whether any of them says something you would object to — someone still has to read them, and no tool can outsource that judgment. What an inventory buys is the end of not knowing they exist, which is where most of the actual risk lives.

Nor is a file-based audit a security boundary. The strong control is sandboxing: run unfamiliar code and unfamiliar instructions in a container or VM with no credentials, and the question of what the repo told your agent becomes much less interesting. An inventory is the cheap control you will actually perform; isolation is the expensive one you should perform when the stakes justify it. Use both, in that order.

Finally, this list will age. The agent-addressed surface has grown every year since it appeared, and new filenames and new event types will keep arriving. The durable habit is not the specificfind command above — it is the question: what in this checkout is addressed to my agent rather than to me?

The bottom line

Before you point an agent at a repository you did not write, spend sixty seconds finding out what that repository has to say to it. Instruction files — including the nested ones. Hook commands, because those execute. Declared MCP servers, especially unpinned ones. Shipped skills. Then put those paths in CODEOWNERS so the second, third, and hundredth change gets the same look as the first.

The tool is free, MIT, and stays that way: whats-inherited-mcp. It sits with the other two servers and the two paid kits on our agent tools page. If your concern is agents that report work they did not do, that is a different failure with a different fix — the Agent Reliability Kit ($29), written up in your agent says it's done and it isn't.