[BUG] Plan mode's read-only guarantee is not enforced for subagents dispatched via the Agent tool

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?

Plan mode is documented to the model as an absolute restriction — no edits, no non-read-only tool calls, for the whole session, explicitly stated to supersede any other instruction. In practice, subagents dispatched via the Agent tool while plan mode is active are not bound by that restriction at all. A subagent (an "Explore"-type agent, documented as read-only-by-design) executed a destructive shell command (rm -f against a wildcard-style target) during an active plan-mode session, with no permission prompt, no block, and no error. Nothing was actually deleted only because the wildcard happened to match no files — the command still executed successfully. The only reason this was caught at all is that the subagent self-reported it in its own final text summary; nothing in the system verified or enforced anything.

This is not a new or isolated report. The identical bug class has been reported at least eight times since January 2026 (full list below), including at least one confirmed real-world incident of a subagent running destructive DELETE scripts against production data. Most of those reports were closed via automated stale-bot closure ("not planned," inactivity-based) rather than triaged or fixed, including the production-data-loss report.

What Should Happen?

While plan mode is active, no tool call anywhere in the session — including tool calls made by subagents spawned via the Agent tool — should be able to execute a write, delete, move, or other non-read-only action, regardless of whether the dispatching prompt restates the restriction. Plan mode should be a session-wide, tool-layer enforced state, not something that depends on the orchestrating model remembering to manually re-communicate it to every child agent it spawns, and not something that silently falls back to a separate, more permissive policy (per #64162, subagents in plan mode appear to be governed by the auto-mode classifier instead of plan mode itself).

Error Messages/Logs

None. This is the core of the problem: the destructive tool call executed silently — no denied-permission error, no warning, no log entry of any kind. The only trace was the subagent's own voluntary self-disclosure in its final response text.

Steps to Reproduce

1. Start a Claude Code session and enter plan mode.
2. While in plan mode, have the model dispatch a subagent via the Agent tool (e.g., an "Explore"-type agent) for a read-only research task, without the dispatch prompt explicitly re-stating the plan-mode restriction.
3. Note the subagent has Bash tool access by default — agent types intended for read-only search are not actually restricted from Bash at the tool-grant level.
4. Have the subagent run a destructive command via Bash (e.g. rm -f against a target).
5. Observe: the command executes with no block, prompt, or error, despite plan mode being active for the whole session.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.22209.0 (Desktop App using Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Desktop App (Claude Code uses both Powershell and Bash)

Additional Information

Confirmed real-world impact: #64056 ("Subagent autonomously ran destructive DELETE scripts against production data," labeled data-loss) shows this is not a theoretical risk — it has already caused actual data loss for at least one user.

Full related-issue history (same underlying pattern — subagents/skills not properly bound by the parent session's active permission state — manifesting across several specific mechanisms and in both directions, under-blocking and over-blocking):

Open:

#18950 (Jan 2026) — user-level settings.json allow-rules not inherited by skills/subagents (inverse symptom: over-prompting on safe commands, not under-blocking destructive ones).
#78063 (Jul 2026) — disallowedTools not inherited by subagents spawned via the Agent tool.
#77838 (Jul 2026) — deny permission rule for backgrounded agents not enforced on the Agent tool.
#78345 (Jul 2026) — plan mode over-prompting regression, from a fix explicitly targeting "plan mode auto-running file-modifying Bash commands... without a permission prompt." Unclear whether that fix's scope covers the subagent-dispatch pathway at all.

Closed (not_planned/stale — not evaluated as invalid or fixed, auto-closed from inactivity):

#43777 (Apr 2026) — "Plan mode constraint not propagated to Agent tool subagents" (earliest report of this exact issue).
#57118 (May 2026) — subagent permission-mode inheritance broken for Edit tool calls.
#63762 (May 2026) — Workflow-tool subagents always granted Write/Edit regardless of allowlist.
#64056 (May 2026) — confirmed production data loss (see above).
#64162 (May 2026) — most mechanistically precise prior report: subagents in plan mode fall through to the auto-mode classifier rather than being bound by plan mode.
Process observation, separate from the technical bug: multiple reports of this issue, including a confirmed data-loss incident, were closed by automated stale-bot processes rather than human triage. That's a compounding problem independent of the underlying permission-inheritance bug itself.

Related finding, same investigation: Bash tool calls in this environment were not confined to the project's working directory — reading paths outside the active project folder succeeded with no block or prompt, suggesting no default directory-scoped sandbox boundary exists even outside of plan mode.