Spawning a sub-agent fails outright if its disallowed-tools list can't actually be applied.
What's wrong with this entry?
When a workflow spawns a sub-agent, every entry in its disallowedTools list is now checked against the tools that agent would actually get. Anything that cannot be matched aborts the spawn with an explanation instead of quietly running the agent with the restriction dropped. Entries that parse fine but match nothing log a "no-op here" warning and the spawn continues.
- rejected: a stray space before rule parentheses, unbalanced parentheses, an empty server name in an
mcp__entry, wildcards inside an MCP server or tool name, and*used outside anmcp__spec - also rejected: entries that are not non-empty, non-whitespace-padded strings, and
bashCommandClampentries that do not parse as a Bash permission rule with real content - case-mismatched or misspelled MCP entries are caught by a new analyser that classifies each entry as a declared server, a server present in the pool, a near-miss with a suggested correct spelling, or unmatched
agent() opts.disallowedTools unparseable entry, Refusing the spawn rather than running it un-narrowed.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
Deny rules match batched tools by the original tool name
Both mention disallowed tool