[BUG] Plan mode's subagent reminder (SlT) tells background subagents to write a plan and call AskUserQuestion, which they cannot do

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary: The plan-mode reminder rendered for subagents is a separate, dedicated code path from the one rendered for the main session, and its copy is written for an interactive recipient that a background subagent is not. It tells the agent the user does not want it to execute yet, instructs it to write a plan file, and directs it to "answer the user's query" using AskUserQuestion. A background subagent has no user turn, no query, an assignment its parent already approved, and — in most subagent types — no AskUserQuestion tool at all.

The branch is explicit. In the 2.1.235 darwin-arm64 build:

function mlT(e){ if(e.isSubAgent) return SlT(e); if(e.reminderType==="sparse") return blT(e); return _lT(e) }

SlT is the subagent renderer. The main-session renderer _lT pulls in a separate function containing the Phase 1–5 plan workflow and the ExitPlanMode instruction; SlT contains neither. Symbol names are minified and build-specific — the verbatim strings below are the stable anchor.

Three differences between the two rendered strings, each defective in the subagent direction:

1. The main-session string carries (with the exception of the plan file mentioned below). SlT omits it, so the subagent text forbids all edits and then instructs it to write a file.
2. SlT's opening ends ... Instead, you should: — and nothing completes the sentence. In _lT that lead-in is followed by the workflow. In SlT the workflow is absent and the dangling clause remains.
3. In the workflow's place, SlT emits Answer the user's query comprehensively, using the ${bg} tool if you need to ask the user clarifying questions, where bg is AskUserQuestion — the same identifier _lT's exit-instruction helper uses.

Impact. There is no correct reading available to the recipient, so the model improvises one, and the improvisations do not converge. Observed outcomes, all from ordinary background subagents dispatched via the Agent tool with run_in_background: true:

• Assignment abandoned pending approval. A subagent tasked with reading a directory of note files, classifying each against a CLI call, and writing a summary report wrote its per-agent plan file and ended its turn: "I've written a plan… since plan mode is active in this session and I can't run the remaining write/edit steps… until you approve." It stayed there until the parent noticed the truncated hand-back and manually messaged it ~4 minutes later. A second subagent, tasked with checking git state across a worktree, produced the same shape: "I've drafted a plan rather than executing everything now."
• Authorized work silently dropped. A subagent tasked with scanning project files and writing a short status note concluded it was restricted to read-only, skipped its write, and returned a normal-looking report that does not mention the skipped write. Indistinguishable from a clean run.
• Unrequested plan file, assignment completes. Several subagents wrote a plan for work nobody asked to have planned, then finished normally. One is titled "read-only reporting task" and its body argues the agent does not need a plan.
• Reminder disregarded, situation reported. One subagent finished normally and flagged it: "I disregarded an anomalous 'plan mode' system-reminder that appeared with no preceding user turn and no way for a non-interactive background agent to satisfy it." The good outcome — and the agent's own judgment, not something the mechanism provides.

The first two lose work; the second loses it invisibly.

This is not a request to stop propagating plan mode to subagents. Plan mode is a permission mode and should reach them — without that, "enter plan mode, spawn an agent, do the writes" defeats it. Nor is this about the write-approval prompts: plan mode is entered by a human who is present, so those are generally answerable. Every failure above happens before any tool call that would prompt. The agents stopped, skipped, or improvised on the strength of the text.

What Should Happen?

SlT should describe the recipient's actual position and not instruct it to plan or to call a tool it does not have. Approximately:

The parent session has entered plan mode. Writes from this subagent will require interactive approval and may be delayed or refused. You have not been asked to produce a plan. Continue your assigned task; if a tool call is refused, report it rather than retrying or stopping.

Two secondary asks:

1. Apply the same treatment to the wider mode-reminder stream. An ## Auto Mode Active reminder carrying git-safety instructions about git checkout / reset / rm -rf also reached a read-only background survey agent unrequested. Plan mode is the instance that changes behaviour, but it is not the only reminder crossing over.
2. Record mode-change reminders in subagent transcripts. sFa() builds the attachment with isSubAgent:!!e.agentId computed correctly, but "type":"plan_mode" never appears in a subagent's transcript, while the parent's records it. The effect is on disk and the cause is not, which is a large part of why this has been hard to diagnose (see #75372).

Error Messages/Logs

# --- Rendered for the MAIN SESSION (_lT) ---
Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT
make any edits (with the exception of the plan file mentioned below), run any non-readonly tools
(including changing configs or making commits), or otherwise make any changes to the system. This
supercedes any other instructions you have received.

## Plan File Info:
No plan file exists yet. You should create your plan at
/Users/<user>/.claude/plans/<slug>.md using the Write tool.
[...]
## Plan Workflow
### Phase 1: Initial Understanding  [...]
### Phase 5: Call ExitPlanMode


# --- Rendered for a SUBAGENT (SlT), same plan-mode entry ---
Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT
make any edits, run any non-readonly tools (including changing configs or making commits), or
otherwise make any changes to the system. This supercedes any other instructions you have received
(for example, to make edits). Instead, you should:

## Plan File Info:
No plan file exists yet. You should create your plan at
/Users/<user>/.claude/plans/<slug>-agent-<agentId>.md using the Write tool if you need to.
You should build your plan incrementally by writing to or editing this file. NOTE that this is the
only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
Answer the user's query comprehensively, using the AskUserQuestion tool if you need to ask the user
clarifying questions. If you do use the AskUserQuestion, make sure to ask all clarifying questions
you need to fully understand the user's intent before proceeding.

Steps to Reproduce

1. Dispatch a background subagent via the Agent tool with run_in_background: true, with an assignment that involves writes.
2. Enter plan mode in the parent session.
3. Observe the subagent's next turn, and ~/.claude/plans/.

The reminder is not delivered at spawn — it arrives after the subagent's first tool batch. An agent dispatched during plan mode and one interrupted mid-run therefore reach it by the same path and receive identical text.

Self-check for whether you have already hit this: ls ~/.claude/plans/ | grep -- '-agent-a'. Each match is a plan file a subagent produced without being asked. It marks an affected run, not necessarily a failed one.

Expect the outcome to vary between attempts. The reminder is identical every time; what the agent does with it is not. A single run may well land on one of the benign outcomes above, and that is not evidence against the report — it is the report. The copy admits no correct reading, so which outcome you get is left to the model.

Claude Model

Opus (parent). Subagent behaviour verified on both Opus and Sonnet.

Is this a regression?

No — long-standing.

Last Working Version

n/a. The SlT string is byte-identical to captures taken on 2.1.228 and 2.1.234, so the behavioural cases below were produced by the same text 2.1.235 still delivers.

Claude Code Version

2.1.235 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Method. Two rounds of probes, each an ordinary general-purpose background subagent told openly what the experiment was and asked to report what it received rather than to disregard it. Round one captured the subagent string; round two dispatched an Opus subagent and a Sonnet subagent concurrently into the same plan-mode window and confirmed the text is byte-identical across models, differing only in each agent's own agentId in the plan path. So the parent/subagent divergence is by recipient role, not by model. The strings were then confirmed against the shipped binary, which is how mlT/SlT above were found.

Ruling out user configuration. The affected agents' definitions contain no plan-mode handling of any kind — grep -ril "plan mode" across them returns nothing. Hooks are also not involved: a hook with matcher: "" firing on every PostToolUse produced zero output across a subagent's 78 tool calls, while the parent persisted the same hook's output as attachments.

Relationship to existing issues.

• #75372 ("Fabricated <system-reminder> blocks appearing in Agent-tool subagent tool-result streams") is the same phenomenon, reported from the outside. That thread has three independent corroborations and one open question — "is this a known internal harness behavior, or an actual bug/security issue in how tool results get assembled?" — which has been unanswered since July and is now labelled stale. The answer is the former: SlT is a real, authored function, not fabricated content and not an injection. That thread also reports a real-impact case matching the first failure mode above: a subagent that wrote its deliverable to the <plan-basename>-agent-<id>.md path and handed the wrong path back to downstream automation.
• #57751 (closed not-planned) is cited on #75372 as the likely root cause — "subagents inherit parent prompt cache → plan-mode bleed". Given mlT's explicit if(e.isSubAgent) branch, that diagnosis does not appear to be what is happening here.
• #86255 is adjacent but distinct — misattributed plan-approval dialogs, not reminder copy.

I am happy to provide sanitized subagent transcripts on request.