Follow Discord
Sweep 10 Nov 2026 · 02:18Z Build v2.1.322 539 read Stable v2.1.311 Latest v2.1.322 Next v2.1.322 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.257 ·

Agent/settings permission-mode 'widening' now blocked with new telemetry

An agent definition's permissionMode can no longer widen the mode inherited from its parent context.

You'll notice Bug Fixes
JSON All of v2.1.257
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
PermissionsArea: what it touches
Bug FixesKind: in v2.1.257,
What probably matters to youSection of the release

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.

Read from
Names in the bundlepermissionMode
Since it was published

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
How sure we are
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up permissionMode, on Configure permissions.
Anthropic's release notes agreeFixed sessions dispatched from an agent view opened with ← always starting in the original session's permission mode, overriding the target…

See this entry in the whole of v2.1.257 →

Feedback