Workflow subagents don't inherit project settings.local.json permission allow-rules (prompt per tool call)

This looks like a permission-context propagation bug rather than only a prompt-volume problem.

If a workflow subagent is spawned inside a session where WebSearch, WebFetch, Agent, or MCP is already allowed by the resolved project policy, the child run should inherit a bounded permission snapshot. But that snapshot should stay explicit and scoped, not become ambient authority.

The failure mode cuts both ways:

• no inheritance: every child read-only call prompts, which pushes users toward broad bypass modes just to make workflows usable
• unbounded inheritance: a child agent may silently gain more authority than the parent intended

A safe contract could bind the inherited permission snapshot to:

• parent session id
• workflow id
• child agent id
• project root or settings digest
• tool name and operation family
• allow or deny decision source
• expiry or child-run scope
• whether the permission came from user, project, local, or session state

Tests I would add:

• direct WebSearch allowed by project policy does not prompt
• subagent WebSearch in the same workflow inherits the same allow decision and does not prompt
• deny rules override inherited allow rules
• a subagent cannot expand from WebSearch/WebFetch into Agent or MCP unless those are explicitly allowed
• settings digest change during a workflow forces recompute or prompt
• inherited permission is visible in the run record so the user can audit why no prompt appeared

That keeps deep-research-style workflows usable without making permission inheritance invisible or broader than the parent session approved.

Boundary: architecture and conformance feedback only; no claim about Anthropic/Claude Code alignment, implementation correctness, acceptance, partnership, integration, customer interest, official alignment, Claude Code usage, or Neura usage.

I ran into the same problem, but only in Plan Mode.

I ran a controlled A/B test that isolates this specifically to Plan Mode, separate from the general allow-list-inheritance question this issue tracks.

Setup: Project-level .claude/settings.json and .claude/settings.local.json both allow-list mcp__intellij__find_files_by_name_keyword. I additionally synced the same rule to user-level ~/.claude/settings.json to rule out a settings-scope gap. Then I ran the identical tool call (mcp__intellij__find_files_by_name_keyword) via the identical subagent type (Explore, built-in), toggling only whether the main session was in Plan Mode.

Results (replicated):

| Run | Main session mode | Tool call (via Explore subagent) | Permission prompt shown? |
|---|---|---|---|
| 1 | Plan Mode | find_files_by_name_keyword | Yes |
| 2 | Manual/default | find_files_by_name_keyword | No |
| 3 | Plan Mode | find_files_by_name_keyword | Yes |
| 4 | Manual/default | find_files_by_name_keyword | No |
| 5 | Plan Mode | find_files_by_name_keyword | Yes |

3/3 in Plan Mode → prompted. 2/2 outside Plan Mode → not prompted. Tool, subagent type, and allow-list state were held constant across all runs — only the main session's mode changed.

This contradicts the permission-modes docs, which state: "Permission prompts still apply as they do in Manual mode" for Plan Mode. In practice, subagent-originated MCP tool calls made while the parent session is in Plan Mode appear to force a permission prompt regardless of permissions.allow entries at either project or user scope. Outside Plan Mode, the same allow-listed tool call from the same subagent type does not prompt.

Environment:

• Claude Code CLI version: 2.1.200
• OS: Windows 11
• Shell: Git Bash (also reproduces with the IDE-integrated PowerShell terminal)
• Model: Claude Opus 4.8
• MCP servers involved: intellij (JetBrains IntelliJ MCP plugin, registered at user scope via claude mcp add -s user) — the prompt was against the user-scope intellij server, so this isn't specific to project-scope .mcp.json trust gating.
• Subagent type: built-in Explore (not a custom .claude/agents/ definition, so agent-level permissionMode frontmatter doesn't apply here)

@lpieprzyk Just adding that I can reproduce the same findings. Thanks for sharing them, as moving out of plan mode can work around this in some circumstances (at least until this gets hopefully fixed).

Still reproducing on 2.1.204 (macOS 26.6, Opus 4.8).

MCP tools that are allow-listed at both project (.claude/settings.json) and
user (~/.claude/settings.json) scope still trigger an approval prompt on
subagent-originated calls. In my case the affected servers are brave-search
(mcp__brave-search__*) and context-mode
(mcp__plugin_context-mode_context-mode__ctx_execute) — so this isn't specific
to the intellij server in @lpieprzyk's repro, and nothing in the 2.1.201–2.1.204
changelogs addresses it.

I haven't re-run @lpieprzyk's controlled Plan-Mode A/B on 2.1.204, so I can't
independently confirm the Plan-Mode correlation at this version; flagging only
that the core symptom (allow-listed MCP tools prompting from subagents) persists
on the latest release.

This one is particularly rough for deep-research or any workflow that fans out to many read-only tool calls, because the workaround -- approve each call manually -- is not just annoying, it serializes what should be parallel work. Clicking through 100 WebSearch prompts defeats the point of running a workflow.

The permissions model here should treat subagents as executing within the session that spawned them. If WebSearch is allowlisted in .claude/settings.local.json for the project, a subagent running that workflow in the same project context is not a different security principal -- it is the same user's work.

A few edge cases worth calling out if this gets prioritized:

1. The inheritance should be scoped to read-only/non-destructive tools by default (WebSearch, WebFetch, Read). Write-capable tools (Bash, Edit, Write) arguably deserve a conscious allowlist even in subagents.

1. settings.local.json vs. settings.json distinction matters: local settings are per-machine and not committed, which is exactly where users put aggressive allow-rules. Subagents should respect both layers, with local taking precedence as it does in the main session.

1. This also blocks running workflows in CI/CD contexts where there is no human present to approve prompts. A workflow that cannot run non-interactively because subagents keep pausing for approval is not useful for automation.

Worth linking to #70591 (centralized approval notifications) -- these two issues describe opposite sides of the same gap: one needs subagents to not prompt when already allowlisted, the other needs a way to batch-approve when prompting is appropriate.