You'll notice
An agent definition's permissionMode can no longer widen the mode inherited from its parent context.
Permission-mode resolution now detects when an agent's frontmatter permissionMode would widen the effective mode inherited from a parent or agent view, and ignores that widening instead of applying it. This closes a path where a repo-controlled agent definition could loosen permissions beyond what the parent context allowed. The event tengu_agent_frontmatter_mode_widening_carry_ignored is logged whenever this happens.
Names in the bundlepermissionMode
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added since
A small documentation edit on Plugins reference touched a line naming permissionMode after this was published.
For security reasons, plugin-shipped agents don't support `hooks`, `mcpServers`, or `permissionMode`.plugins-reference see the edit
Confirmed since
Anthropic's documentation has since written up permissionMode, on Configure permissions.
For a locked-down agent, pair `allowedTools` with `permissionMode: "dontAsk"`:agent-sdk/permissions see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up permissionMode, on Configure permissions.
Anthropic's release notes agree
Fixed sessions dispatched from an agent view opened with ← always starting in the original session's permission mode, overriding the target…