What you will learn
- Explore and Plan are the only Claude Code subagents that skip your CLAUDE.md, and there is no setting to change it
- How to check, in about two minutes, which of your agents can actually see your rules
- What an ETH Zurich benchmark found when it measured whether context files help at all
- Why the answer never appears in your session transcript, so you cannot audit it later
Claude Code reads your CLAUDE.md into every subagent it spawns, with two exceptions. The built-in Explore and Plan agents skip it. Anthropic’s subagents documentation states the rule and then closes the door on working around it: there is no frontmatter field and no per-agent setting that changes which agents skip the file.
That is a strange shape for a governance tool. You write CLAUDE.md so the machine follows your rules. Then the two agents built for the widest fan-out, the ones you spawn ten at a time to sweep a codebase, are the two that never open it.
The tradeoff is deliberate and defensible. It is also almost never discussed, and it interacts badly with a second thing nobody discusses: the file you are not shipping to those agents may not be helping the ones that do receive it.
What Explore and Plan skip
Each non-fork subagent starts with a fresh, isolated context window. It gets its own system prompt, the delegation message Claude writes when handing off, any skills named in its skills field, and a sibling roster if it can message other agents. Two more items arrive for most agent types and not for these two:
“Explore and Plan are the only subagents that omit CLAUDE.md and git status. There is no frontmatter field or per-agent setting to change which agents skip them.” — Claude Code subagents documentation
Everything else loads the whole hierarchy. The user-level file at ~/.claude/CLAUDE.md, the project file, CLAUDE.local.md, project rules, managed policy files. A general-purpose agent gets all of it. So does every custom agent you define in .claude/agents/. A fork gets more still, because a fork inherits the parent conversation wholesale rather than starting clean.
One detail cuts against the simple version of this story. The skills listing does reach Explore agents, and skill descriptions are prose you wrote. So an Explore agent running on a machine with a well-described skill library is not rule-free. It can see, for instance, that a cache purge needs legacy auth headers, because that sentence lives in a skill description rather than in CLAUDE.md. The channel is narrow and you did not design it as a governance channel, but it is open.
Anthropic’s reasoning for the exclusion is cost and speed, and their suggested workaround is worth reading closely, because it quietly concedes the point. The main conversation reads Explore and Plan results with full CLAUDE.md context, so most rules do not need to reach the subagent. If a rule must reach it, restate that rule in the prompt you give Claude when delegating. Which is to say: for the two agents you run most often, your instruction file is advisory at best, and the actual mechanism is you remembering to paste the rule into the request.
Measuring the gap on a real file
You do not have to take the documentation’s word for any of this. The check takes about two minutes and it is worth running on your own setup, because the answer depends on which agent types you actually use.
Pick a string that appears only in your CLAUDE.md and nowhere else on disk. A registration number works well. A distinctive heading works. Then spawn one Explore agent and one general-purpose agent, give both the same instruction, and tell both to use zero tools and answer only from the context they were handed. Ask whether that string is present, and ask them to quote the surrounding words if it is.
The Explore agent reports the string absent, along with every other marker from the file. The general-purpose agent quotes it back verbatim, names both CLAUDE.md paths it was given, and describes the two files concatenated under a single header. Same session, same working directory, same model, opposite answers. Run it twice on different days and the result holds.
Two numbers from that check are worth writing down. A two-file hierarchy in daily use, one global and one project-level, came to 28,449 words and 214,976 bytes. And the general-purpose agent that made zero tool calls, did no work, and answered one introspection question still reported 111,253 tokens for the turn. That is the floor. Every general-purpose agent in a fan-out pays something like it before it reads a single line of your code.
The file also moves. A measurement taken on one day recorded 209,907 bytes; the same two files 24 hours later came to 214,976. Roughly five kilobytes arrived overnight, because that is what instruction files do. Any figure you write down about your own CLAUDE.md has a short shelf life, which matters if you are budgeting against it.
Does a bigger instruction file help?
Here the question stops being about Claude Code and starts being about whether any of this earns its place. A team at ETH Zurich and LogicStar.ai ran the experiment. They built a benchmark called CTXBENCH from 138 real GitHub issues across 12 repositories that carry developer-committed context files, paired it with SWE-bench Lite, and ran four agent and model combinations through three conditions: no context file, an agent-generated one, and the developer-written one.
“Surprisingly, we find that providing context files does not generally improve task success rates, while increasing inference cost by over 20% on average. This observation holds across different LLMs, coding agents, and for both LLM-generated and developer-committed context files.” — Thibaud Gloaguen and colleagues, Evaluating AGENTS.md, June 2026
The detail underneath that abstract is sharper than the summary. Agent-generated context files dropped the resolution rate by 0.5% on SWE-bench and 2% on CTXBENCH, at p-values of 87% and 37%, which the authors read as no effect rather than a penalty. Developer-written files did better at 2.4% on average, but at p equals 21% that is also not a result you would bet on. What did move, with p below 0.001%, was cost: 20% and 23% higher, because the agent took two to four more steps per task.
Then two lines that should change how you write the file. First, instructions in context files are followed well; it is the repository overviews, the part every vendor recommends, that the paper finds unhelpful. Second, developer-written files improved performance for every agent tested except Claude Code.
The size comparison is where this lands hardest. The mean context file across their benchmark is 641 words, and the largest is 2,003. The 28,449-word pair from the check above is roughly 44 times their average and 14 times their biggest. Whatever the paper measured, it did not measure a file like that, and there is no reason to assume the curve stays flat out there. The fair reading is that the research has no data on files this size, and the burden sits with the person who wrote one.
I do not think the conclusion is to delete your CLAUDE.md. The paper does not say that either; it says context files are useful for non-standard practices that an agent cannot infer, and that anything beyond that should be evaluated before you deploy it. What the result argues against is the reflex of treating the file as a place where more is safer. Repository overviews, directory listings, inventories of things the agent could discover by looking: that material is the bulk of most large CLAUDE.md files, and it is the exact category the measurement found inert.
Why you cannot audit this after the fact
There is one more property of this system that makes it harder to reason about than it should be. The CLAUDE.md injection is not written to the session transcript.
Claude Code stores subagent transcripts on disk, one JSONL file per agent, under ~/.claude/projects/{project}/{sessionId}/subagents/. That looks like an audit trail, and for tool calls and messages it is one. But the instruction-file block delivered at startup does not appear in those files, and it does not appear in the main session’s transcript either. Sweeping thousands of stored subagent transcripts for a marker string from your CLAUDE.md returns nothing, in exactly the same way for agents that received the file and agents that did not.
Call that out plainly, because the absence looks like evidence. A search across every subagent transcript on a machine comes back clean and reads as proof that no subagent ever gets CLAUDE.md, which is false for most agent types. The only reliable check is the live one described above: ask a running agent what it can see. Anything reconstructed after the session is over will mislead you.
For most people this is a curiosity. If you work anywhere that has to show which policies were in force for an automated change, it is more than that. The rules your agents ran under are not recoverable from the artifacts the tool leaves behind, so if you need that record, you have to create it yourself at the time.
Write for the agent that actually reads
A few things follow from all this, and they point the same direction.
Treat agent type as the cost lever it is. Explore and Plan skip the file, which makes them the cheap option for wide read-only fan-out, and plan-mode research already defaults to Explore for this reason. A general-purpose fan-out pays your full instruction file per agent, ten agents deep. That is a real decision with a real bill, and it is invisible at the moment you make it. I covered the surrounding economics in the cost of a large context window and the tool-by-tool comparison in subagent vs parallel agent vs skill.
Restate load-bearing constraints in the delegation prompt. If a rule really must reach an Explore agent, the only channel is the request itself. Anthropic says so directly, and it is cheap to do once you accept that the file is not doing that job for you.
Move procedures into skills. A skill’s body loads when invoked rather than sitting in context for every turn of every session, which is the correct home for anything shaped like a checklist. The distinction between the two, and which one to reach for, is the agent types question underneath most of this.
And cut the overviews. If the ETH result holds anywhere near your file size, the repository tours and inventories are paying rent in every general-purpose agent you spawn while contributing nothing the agent could not have found by looking. Instructions earn their place. Descriptions of your own directory structure mostly do not.
Related reading
This is the loading half of a set. CLAUDE.md hierarchy covers how the files stack and what to lock. One root CLAUDE.md across an organization covers what happens when you try to make one file serve every Claude product at once.
What nags at me is that a large CLAUDE.md creates a specific illusion. It looks like control. You can point at it, it is in version control, it grows every time someone learns something. Meanwhile two of the agent types running against your codebase have never opened it, the measurement says the biggest section of it was not helping the ones that did, and nothing in the session record will tell you which was which. If you want the file to be doing a job, the first move is finding out what it currently does. That check takes two minutes and most people have never run it.





