[BUG] Subagent disallowedTools with a path rule (e.g. Write(dir/**)) removes the whole tool instead of denying that path

Summary

In a subagent definition, a disallowedTools entry that carries a path rule (for example Write(reports/**)) removes the whole tool from the subagent, not just the paths the rule names. A subagent meant to lose Write access to one directory ends up with no Write or Edit tool at all.

The same syntax works as expected in the tools allowlist. A subagent with tools: Write(reports/**) keeps a working Write tool, limited to that path.

Reproduction

Claude Code 2.1.282, macOS.

claude -p --model haiku --permission-mode bypassPermissions --agents '{
  "scoped": {
    "description": "probe scoped",
    "prompt": "Report the exact names of every tool you have, comma separated, nothing else.",
    "tools": ["Read", "Edit", "Write"],
    "disallowedTools": ["Write(forbidden/**)", "Edit(forbidden/**)"]
  },
  "plain": {
    "description": "probe plain",
    "prompt": "Report the exact names of every tool you have, comma separated, nothing else.",
    "tools": ["Read", "Edit", "Write"]
  }
}' "Spawn the agent 'scoped' and then the agent 'plain' with the Agent tool, each with the prompt 'list your tools'. Reply with exactly two lines: 'scoped: <its answer>' and 'plain: <its answer>'."

Output:

scoped: Read
plain: Read, Edit, Write

The same thing happens with a file-based agent in .claude/agents/*.md:

tools: Read, Grep, Glob, Edit, Write, Bash
disallowedTools: Edit(reports/**), Write(reports/**/report.md)

When that subagent calls Write, it gets:

<tool_use_error>Error: No such tool available: Write. Write is disabled for this session, in subagents as well as here.</tool_use_error>

Expected

A path rule in disallowedTools should act as a deny permission rule: Write and Edit stay available, and only calls matching forbidden/** are refused. This matches how the same rule syntax behaves in permissions.deny and in the subagent's tools allowlist.

If path rules aren't supported in subagent disallowedTools, the definition should fail to load with a clear error, rather than silently removing the tool.

Impact

This fails silently and is hard to diagnose:

• Misleading error. The message "disabled for this session, in subagents as well as here" suggests a setting that covers the whole session. No such setting exists, and nothing points to the agent's own frontmatter.
• Hooks are bypassed. A subagent whose job is editing files falls back to writing through Bash (heredocs, sed -i). That skips any PostToolUse hook keyed on Edit or Write, such as lint and test gates.
• The obvious workaround costs access. To keep one subagent away from one directory, the only option is to drop the path rule. That gives the subagent write access to the directory the rule was meant to protect.