Subagents and Workflow agents cannot use permission-gated MCP tools; no way to pass user authorization to assuage automode classifier or surface the request

What happens

A parent session that is allowed to use a permission-gated MCP tool spawns subagents (via the Task tool or the Workflow tool). When a subagent calls that same MCP tool, the call is refused — the refusal text says the call was denied by the Claude Code auto mode classifier / blocked by classifier. The parent session's identical call to the same tool succeeds. The subagent does not inherit the session's approvals.

Observed

In one workflow run, 4 subagents made 10 attempts at the same read-only MCP database tool (mcp__mydb__execute_sql). Every attempt was refused, while the orchestrating session's identical queries went through.

The agents' prompts stated explicitly that the user had authorized read-only access to that tool for that task. This made no difference — which is expected if the classifier evaluates the tool call rather than the instructions the calling agent was given.

Why the available workarounds are unsatisfactory

1. Authorization in the subagent's prompt does not work (observed above).
2. Adding the tool to permissions.allow works, but is the wrong shape. It is a blanket, permanent grant that bypasses the classifier for every future call in every session. Users who deliberately want the classifier's protection do not want to give it up, and there is no way to scope the grant to "for this workflow run".
3. There is no runtime intervention. The blocked request is not surfaced to the user as an approval prompt, and there is no way to reach into a running workflow, find the agent that was blocked, and tell it to proceed.

What is being asked for — either would solve it

• A way to pass an authorization scope when spawning a subagent or launching a workflow — e.g. an argument on the Task/Workflow invocation naming the tools the user has authorized for that run — that the classifier respects. Authorization then becomes per-run rather than permanent in settings.
• Or: surface a subagent's blocked tool call to the user as an approval prompt, so the user can unblock that specific call while the workflow waits.
• Means of accessing a workload agent that is marked as blocked and talk to him (to unblock him)

Impact

Workflows that need to check facts against a real data source — reviewing code against production data, verifying a migration, checking whether a bug's trigger state actually occurs — currently cannot do so at all. The agents carry on reasoning without the data, which produces confident findings that the data would have refuted.

Environment

• Claude Code CLI on macOS
• Subagents spawned via the Task tool and via the Workflow tool
• MCP server configured at user scope
• Auto mode / accept-edits permission mode

Related issues

Neighbouring reports that do not cover this case, listed so triage can link them:

• #85982 — auto-mode classifier trust inheritance for subagents is unreliable (intermittent, destination-keyed file-write denials; no per-run authorization ask)
• #73633 — workflow subagents don't inherit permissions.allow rules (they prompt per call rather than being classifier-denied)
• #83611 — a tool listed in permissions.allow is denied by the classifier
• #69482 — subagent permission prompts are invisible in remote/web sessions