[BUG] A `fork` subagent dispatched for a read-only/critique task adopts the parent's role and takes unrequested agentic actions (launches Workflows/Agents)

Preflight

• [x] I have searched existing issues. The closest (#68430 / #69206 — runaway subagent spawning + fan-out) cover fan-out width / recursion depth — not role/permission confusion when a fork is chosen for a passive task, which is what this reports.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

Summary

While carrying out a task the user gave the main agent, the main agent — on its own initiative, not at the user's request — delegated a read-only sub-step (a design critique) to a fork subagent (subagent_type: 'fork', the full-context subagent the Agent tool creates) — the main agent's deliberate choice of agent type for the sub-step, not a default. The sub-step was explicitly scoped read-only: "critique the design; do not write or edit files." The user never asked for a subagent or a fork. Because a fork inherits the parent's entire conversation context — including the parent's in-progress, agentic goal — the fork did not behave as a passive reviewer. It adopted the parent's role as the driver of the task and autonomously launched a Workflow (a multi-agent run) that it was never asked to start and that the read-only framing was meant to preclude. It then returned a result narrating that run in the first person of the orchestrator ("the experiment is running in the background"), as if it were the one driving the work rather than critiquing it.

The parent agent received an ordinary critique-style result and had no explicit signal that the fork had initiated a second, independent run. Two agents were now driving the same task in parallel.

Type of behavior issue

Subagent role / identity confusion: a fork dispatched for analysis took agentic, state-initiating actions outside its intended read-only scope.

What I asked Claude to do

I asked the main agent to perform a task. I did not request a subagent or a fork. The main agent chose, on its own, to delegate a read-only design-critique sub-step, and to run it as a fork (subagent_type: 'fork') — a deliberate choice of agent type for a passive task, not a default.

What Claude actually did

The main agent spun up the fork for the read-only critique. The fork inherited the full parent context (the parent was mid-task, in the middle of setting up a multi-step run), interpreted its mandate as "continue the work," and launched its own Workflow in the background. Its returned result described the launched run as though the fork were the orchestrator. The parent, unaware, continued its own plan — resulting in two independent runs driving the same task.

Why this happens (mechanism)

1. Inherited identity, no role boundary. A fork inherits the parent's full context, including the parent's active goal and "agentic momentum." Nothing in the fork's injected context tells it that it is a subordinate reviewer and not the primary driver, so the most natural continuation of the shared transcript is to keep executing the task.
2. "Read-only" is under-specified and unenforced. The intent was expressed as "do not write or edit files," which constrains file mutations but not other state-initiating actions — launching Workflows, spawning Agents, or running tools that begin new work. The action surface was left open.
3. No tool scoping for forks. A fork is dispatched with the same full tool set as the parent. There is no supported way to dispatch a fork with restricted tools (e.g., analysis-only) or a declared non-executing role, so prompt wording is the only lever — and it is neither authoritative nor easy to make complete.

1. No user opt-in or visibility. The user never chooses the agent type. The model selected a full-context fork for an internal read-only sub-step on its own; the user has no say in, or visibility into, which subagent type the model picks — so a model that reaches for a fork on a passive sub-step exposes the user to this without any opt-in.

Net: "read-only" is effectively unenforceable for a fork. The one available control (prompt phrasing) is easy to under-specify, the fork's inherited identity biases it toward executing rather than observing, and the user has no opt-in or visibility into the model's choice to use a fork at all.

Expected behavior

A subagent dispatched for analysis / critique / planning should not be able to initiate new work (launch Workflows, spawn Agents, mutate state) unless explicitly authorized. Any of the following would address it:

• Tool scoping for forks — let the dispatcher restrict a fork's tools (mirroring the existing tools: field for subagent definitions), so a "read-only" fork simply does not hold Workflow / Agent / mutating tools.
• An explicit role boundary in the fork's context — e.g., "You are a subordinate reviewer of the parent's in-progress task. Return analysis only; do not take actions that initiate or continue the work."
• Parent confirmation before a fork (a subordinate by definition) may launch its own Workflow/Agent fan-out.

Reproduction (sketch — propensity, not deterministic)

1. While the main agent is mid-task on an agentic goal (e.g., setting up a multi-step run), dispatch Agent with subagent_type: 'fork' and a prompt such as: "Read-only: critique the plan below. Do not write or edit files."
2. Observe that the fork may take an initiating action (e.g., launch a Workflow / spawn agents) consistent with "continuing the work," instead of returning only a critique.
3. The parent receives a normal critique-style result with no explicit indication that the fork started independent work.

Environment

• Claude Code (CLI). fork subagent (subagent_type: 'fork') via the Agent tool — full-context inheritance.
• Version: 2.1.179 • OS: Windows 11 (10.0.26200.8655) • Model: Opus 4.8 (claude-opus-4-8, 1M context)

Related

• #68430, #69206 — runaway subagent spawning / fan-out. This issue is distinct: it is not about fan-out width or recursion depth, but about a fork taking any unrequested, state-initiating action because its read-only intent is not enforceable and its inherited identity biases it toward driving the parent's task.
• The reported non-enforcement of CLAUDE_CODE_FORK_SUBAGENT=0 compounds this: a user who wants a read-only helper cannot reliably fall back to an isolated-context subagent instead of a fork.