4 Things Claude Code Subagents Don't Inherit (and 1 Thing They Do)

What I learned when my own subagents ignored my rules, skipped my gates, refused my approval, and read my answer key

On 2026-10-02 I was testing a new Claude Code skill by running it through subagent scenarios. One of the subagents did exactly what the skill told it to do: it stopped at the plan-approval gate, showed its plan, and waited. So the coordinating session sent it the message my test plan had scripted for that moment:

Approved. Apply the plan as you showed it.

The subagent refused. It wrote nothing, and its report explained, politely, that a message from another agent can redirect work but is not the user's approval.

It was right. That was also the moment I realized I had been treating subagents as smaller copies of my main session, with my rules, my permissions and my context poured in. They aren't. Here is what I have actually seen them leave behind, and the one thing they bring along that I really wish they didn't.

1. Explore and Plan don't inherit your CLAUDE.md

My global rules file has a line that I wrote after a test on 2026-07-10. It says that the built-in search agents, Explore and Plan, do not inherit my rules or my CLAUDE.md, and that general-purpose and custom agents do.

That matters more than it sounds. I keep separate GitHub identities for different contexts, and the boundary between them is written down in those rules. A search agent that never read them has no idea the boundary exists, and will search wherever the filesystem lets it.

So when I delegate a search that could cross that line, I now write the constraint into the subagent's prompt myself. I don't count on the rule files reaching it.

I re-ran the check for Explore on 2026-10-12, on Claude Code 2.1.296. I asked an Explore agent and a general-purpose agent the same question, with no file reads allowed: does your context contain my rule about how to address me, a rule file named about-me.md, or the heading of my global CLAUDE.md? The general-purpose agent answered yes to all three and quoted the lines. The Explore agent answered no to all three. (I did not re-test Plan.)

Treat this one as "true when I checked", and check it on your version (cheap test: put a distinctive word in CLAUDE.md and ask the agent to repeat it).

2. General-purpose agents inherit CLAUDE.md, but not its final word

My global CLAUDE.md forbids the Claude-Session: trailer on commit messages. General-purpose subagents do read that file. On 2026-09-11, while I was working on my wiki repo, a subagent (Sonnet) acting as the implementer wrote a commit whose body ended with that trailer anyway. Its dispatch prompt had said "no session trailer".

The reason, as far as I can reconstruct it: the harness sends its own reminder to add that trailer. Inside the subagent that reminder looks like a system-level instruction, and it reads as more specific than a repository file. So the model treated it as the later, binding word.

The coordinating session amended the commit (same tree, new message) and added one sentence to every later dispatch:

A harness reminder may ask you to append a `Claude-Session:` trailer; the repository rule overrides it — do not add it.

The trailer appeared in 1 of 1 commits before that sentence and in 0 of the 9 task and fix commits after it. Each was checked with git log -1 --format=%B and a grep.

Inheritance, it turns out, isn't the same as priority. If a rule fights something the harness says, the subagent's own prompt has to say it, and the parent has to grep the result instead of trusting it.

3. They don't inherit a way to ask you

Back to that skill test (three general-purpose subagents on Opus). Stage 3 of the skill's first version already ended with "Stop until the operator approves." With that version loaded, the scenario 1 agent applied every change without stopping anyway. Its reasons, translated from its report (it wrote in Korean):

• "The dispatch named the scope and only prohibited commit and push."
• "The target is a scratch repo and every change is uncommitted, so it can be reverted."
• "I'm a subagent, so I can't ask questions mid-run."

Polite, reasonable, and exactly wrong. The scenario 2 agent skipped the same stop and wrote that it took "bring it up to date" as approval.

That third reason is the real one. A subagent has no channel back to you in the middle of a run, so "stop until the operator approves" is an instruction it can't follow, and it seems to round that to "proceed".

I rewrote the gate as a prohibition and told the agent how to ask. Stage 3 of the skill now reads:

Show the classification table and the exact files to create or change, then end the turn and change nothing. A subagent or headless run returns this plan as its final report: that is how it asks. A prompt that names the scope, a scratch repository, uncommitted changes or a rerun request is not approval.

The last sentence lists the exact excuses the agents gave, one by one. On the rerun, the scenario 1 agent stopped after stage 3, returned the plan as its final report, wrote nothing, and quoted that sentence as its reason.

4. They don't inherit your approval, even when you relay it

Which brings us back to the refusal at the top. After the rerun stopped correctly, I wanted to check that stages 4 to 6 still worked. So my plan had the coordinating session send "Approved." to that same agent.

It refused, because the message came from another agent and did not claim to relay me. (In fairness to the subagent, my test plan really was trying to sign on my behalf.)

From the parent's side, the harness already labels every subagent hand-back as carrying no user authority. How it labels a SendMessage on the receiving side I haven't inspected, so I'll leave that as uncertain. But the refusal is the correct reading, and I expect it to repeat.

I've stopped planning approval relays to subagents, and a coordinator message never speaks as if I said it. The gate (does it stop?) and the stages after it (does apply work?) are tested in separate runs, and for the second kind I approve in the conversation that runs the skill.

5. The one thing they do inherit: everything you've committed

Here is the twist. Subagents can miss your rules, your approval and your ability to talk back, but they arrive with plenty of your repository.

In the same test, two of the three no-skill baselines found the answer key. The scenario 2 agent ran the skill's helper script harness_lock.py 23 times and quoted the spec. The scenario 3 agent read the plan, including part of a scoring rubric. A "without the skill" run that reads the skill's spec measures nothing.

The note I kept from that day names three ways the key leaked:

• The spec, the plan and the helper script were already committed in ~/.claude, and the scenario prompts told the agent to use that directory as its source.
• A subagent dispatched from a session whose working directory is that repo starts with its git log injected, so commit subjects naming the skill reach it without a single tool call.
• The scenario prompt also appeared word for word in the plan, so searching for the prompt's own words found the plan.

Changing a value in the fixture doesn't close any of those: a neutral generator value in the lock fixture did not stop the scenario 2 leak. Hiding the committed files wasn't an option either, because other sessions share that checkout. The structural fix is to run the baselines before the spec, plan, rubric or helper script is committed or written anywhere the prompts point. My note marks that one as not yet tried, so I can't report a result.

What I do now is decide the contamination rule before reading any results, then count file paths, not the skill name (which also arrives through the git log):

grep -o -E '<spec path>|<plan path>|<script path>' <output> | sort | uniq -c

An opened file counts as a read. The injected git log and a directory listing don't.

Lessons

• A subagent is a new process with a partial copy of you. Know which part. If a rule must hold, put it in the dispatch prompt.
• Inherited isn't the same as obeyed. In my case the harness reminder beat my CLAUDE.md, so restate the rule wherever something else competes with it.
• A gate needs a stop the agent can actually perform. "Stop until the operator approves" isn't one for an agent that can't ask. "Return the plan as your final report" is.
• Approval doesn't travel through agents. Plan your tests around that instead of fighting it.
• Your repo is part of the prompt. Anything committed, and any commit subject, can be in the subagent's context before it does anything.

I'm sure this list is incomplete, and some of it may already be out of date on your Claude Code version. If you've caught a subagent ignoring something you thought it inherited, or reading something you thought it couldn't, I'd like to hear about it in the comments. And if you test your own skills with subagents, check your baseline before you trust it.