Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.308 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.227 ·

agent() refuses spawns whose tool restrictions cannot be applied

Spawning a sub-agent fails outright if its disallowed-tools list can't actually be applied.

You'll notice Improvements
JSON All of v2.1.227
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
SubagentsArea: what it touches
ImprovementsKind: in v2.1.227,
ImprovementsSection of the release
What

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.

Details
  • 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 an mcp__ spec
  • also rejected: entries that are not non-empty, non-whitespace-padded strings, and bashCommandClamp entries 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
Evidence

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.

Read from
Names in the bundledisallowedTools

See this entry in the whole of v2.1.227 →

Feedback