[MODEL] Model attributes the Opus-5-only heron_brook delegation directive to the user's own CLAUDE.md, sending users to audit config for a rule that isn't there

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 0 comments · opened Aug 18, 2026

Preflight Checklist

  • [x] I have searched existing issues for similar behavior reports
  • [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Not a duplicate — please read this first

The heron_brook delegation lines are already well reported: #80988 (canonical, 27 comments), #82371, #82456, #86170, #81263, and #84053 (closed as duplicate). Every one of those is about precedence and configurability — the harness line overriding user config, with no opt-out.

This report is about a different defect: the model misreports the line's PROVENANCE. It does not merely obey the directive — it tells the user the user themselves wrote it. That sends people to audit their own configuration for a rule that is not there, repeatedly, and it is a distinct failure from "the directive wins". Fixing precedence (#80988) would not fix this; fixing this would not fix #80988. I've filed it separately for that reason, and I'm happy for it to be folded in if triage disagrees.

Type of Behavior Issue

Other unexpected behavior — the model attributes an Anthropic-authored system-prompt directive to the user's own configuration.

What You Asked Claude to Do

Ordinary engineering work in a large Go repository, across many sessions and several unrelated projects, where the natural approach was to fan out subagents — broad multi-file searches, parallel independent investigation, or a project skill of mine that explicitly instructs a fan-out.

No prompt of mine ever restricted subagent use. There is no such rule in ~/.claude/CLAUDE.md, in any project CLAUDE.md, in ~/.claude/settings.json, or in settings.local.json.

What Claude Actually Did

  1. Declined to spawn subagents.
  2. **Stated that doing so was disallowed per my own instructions** — variations on "your instructions say not to use subagents unless you request it" / "this is disallowed per your configuration".
  3. On being told no such instruction exists, it did not correct the attribution — it re-asserted it, or hedged that the rule must be somewhere in my setup.
  4. This sent me searching my own config for the rule. I did this more than once, across multiple projects, including two sessions spent with Claude itself trying to locate the phantom instruction. Nothing was found, because nothing is there.
  5. Only when I finally asked for the source to be traced in the binary did the real origin surface — and it is Anthropic's, not mine.

Expected Behavior

Two things, in order of importance:

  1. Never attribute an Anthropic-authored system-prompt directive to the user. If the model declines to delegate because of heron_brook, it should say the restriction is a built-in default, not "your instructions". Misreporting provenance is worse than the restriction itself: a restriction is a constraint the user can work around once they know it exists, whereas a false attribution actively conceals the cause and shifts the debugging burden onto the user's own files. It is unfalsifiable from the user's side — the more carefully they search, the more confused they get.
  1. Ideally, distinguish "the user has not requested it" from "the user has forbidden it". The directive says unless the user requested it, which is silence-defaults-to-off. The model reports it as an active prohibition the user authored. Those are very different claims, and only the first is true.

Files Affected

# Searched for the phantom rule; it exists in none of these:
~/.claude/CLAUDE.md              # no subagent restriction (verified)
~/.claude/settings.json          # no such setting (verified)
~/.claude/settings.local.json    # absent
<project>/CLAUDE.md              # no subagent restriction (verified)

# The actual source — Anthropic's own binary:
~/.local/share/claude/versions/2.1.234

Permission Mode

Accept Edits was ON (auto-accepting changes) — permissions.defaultMode: "auto".

Can You Reproduce This?

Sometimes (intermittent) — the decline is reliable; whether the model blames the user for it varies by session.

Steps to Reproduce

  1. Run Claude Code 2.1.219+ on Opus 5 with no subagent-related rule anywhere in CLAUDE.md or settings.
  2. Give it a task where fan-out is the obvious approach (a broad multi-file search, or a skill of your own that instructs delegation).
  3. When it declines, ask why.
  4. Observe the reason attributed to your instructions or your configuration rather than to a built-in default.
  5. Tell it no such instruction exists, and watch it defend the attribution rather than correct it.

Claude Model

Opus

Relevant Conversation

Paraphrasing the recurring pattern, which is what prompted this report:

Claude: I won't spawn subagents here — that's disallowed per your instructions. Me: I have no such instruction. Where is it? Claude: It's in your configuration — your CLAUDE.md restricts subagent use unless you explicitly request it.

The actual source, traced in the shipped binary on 2.1.234:

$ strings -a ~/.local/share/claude/versions/2.1.234 \
    | grep -c "Do not call the AgentTool unless the user requested it"
3

Assembled as a system-prompt section, gated on Opus 5:

Rgm = ["Do not call the AgentTool unless the user requested it",
       "Do not use workflows or deep-research unless the user requested it"].join(`\n`)

// applied via the heron_brook resolver:
function uJv(e){
  let t = DI()?.tengu_heron_brook;                     // server-delivered override
  if (typeof t === "string" && t.trim() !== "") { ...; return t.trim() }
  let r = tt("tengu_heron_brook", "");
  if (r.trim() !== "") { ...; return r.trim() }
  if (mzo(e)) { H("tengu_heron_brook_applied", {len: Rgm.length, fromClientData: false}); return Rgm }
  return null
}

// gate: Opus 5 prompt bundle only
function mzo(e){
  if (e === void 0) return !1;
  if (sF(jo(e), "opus_5_prompt_bundle") !== !0) return !1;
  return !tt(MJ_, !1)
}

So the text is Anthropic's, hardcoded, and applies to Opus 5 sessions. It is nowhere in my configuration — which is precisely what the model kept telling me it was.

Impact

Medium - Extra work to undo changes

Concretely: several sessions of wasted debugging across multiple projects, chasing a rule that does not exist, plus the ongoing cost of the degraded behaviour itself. The wasted-search cost is entirely attributable to the misattribution, not to the directive.

Claude Code Version

2.1.234 (Claude Code)

Platform

Anthropic API

Additional Context

  • Environment: macOS 26.6.1, arm64, native installer (~/.local/share/claude/versions/).
  • Why this is worth separating from #80988: that thread asks for an opt-out, which is a config-surface change. This asks for an honesty fix in how the model describes a constraint it is under, which is a model-behaviour change and lands in a different place. A user who reads #80988 learns the directive exists; a user hitting this bug never gets that far, because they've been told to look in their own files.
  • The wording invites it. Because the directive is phrased in the second person about the user ("unless the user requested it"), the natural paraphrase collapses into "your instructions say…". If the line stays, phrasing it as a self-identifying default (e.g. "By default, do not call the Agent tool unless the user has asked for it; a standing instruction in user configuration counts as asking") would likely fix both this and half of #80988's ambiguity about what "requested" means.
  • My workaround, for anyone who lands here: an explicit standing authorization in global CLAUDE.md that names the harness strings, states it is the request the default waits for, and instructs the model never to attribute the restriction to me. That satisfies the directive on its own terms rather than fighting it — but it should not be necessary to reverse-engineer a binary to discover that you need it.

View original on GitHub ↗