Claude Code plugin agents honor disallowedTools: block Sume paid tools

Claude Code 2.1.288 (2026-10-02) fixed agent teams so that plugin-defined agents run with their own prompt, tools, disallowedTools, and effort (read 2026-10-03). For Sume that means a plugin can ship a reviewer agent that reads jobs and results but cannot create a paid one, and the restriction travels with the agent. List the paid tool names in its disallowedTools, and give it only the read tools in tools.

The Claude Code line is in the changelog. The Sume tool names come from MCP tools and gates. The sibling case of forked subagents inheriting permission mode is in the fork subagent post.

Why per-agent denial is useful

A session may legitimately hold a Sume credential that can spend, because the person wants to generate media. But not every agent in the session needs that power. A QA agent that checks finished jobs needs jobs_status, jobs_result, and assets_get; a planning agent needs catalog_list and tools_schema. Giving each only what it needs keeps a confused agent from starting a paid job it was never meant to start.

An agent definition

Agent files are markdown with front matter. Tool names for MCP servers in Claude Code follow a mcp__<server>__<tool> convention, which you should confirm in your own session before relying on it. Treat this file as a sketch to adapt.

---
name: sume-reviewer
description: Checks finished Sume jobs. Never starts generation.
tools: mcp__sume__jobs_get, mcp__sume__jobs_result, mcp__sume__assets_get
disallowedTools: mcp__sume__generate_image, mcp__sume__generate_video, mcp__sume__music_create, mcp__sume__tts_create, mcp__sume__jobs_cancel
---
Read job results and report what each job produced. If asked to generate
anything, refuse and name the producer agent instead.

What the server still enforces

Client-side denial and server-side scope are separate layers, and you want both. If the person connected with OAuth and left Write off, Sume itself hides mutating and paid tools and answers insufficient_scope. If they connected with an API key, the server exposes everything, and the agent's disallowedTools is the only barrier in that subagent. Say which case applies in your plugin's README.

When a paid call is allowed, the gates are unchanged: every create needs an idempotency_key, dry_run previews, and max_spend_usd is enforced when provided. For parallel agents creating in the same session, make sure each uses its own key namespace, such as the agent name plus a counter, so two agents never dedupe into one job by accident.

Test the barrier by asking the reviewer to generate an image and confirming the refusal. Then test the producer, and confirm it still can. A plugin whose agents all fail the same way has probably mis-typed the tool names, which /mcp lists exactly.

Rolling it out to a team

Ship the agent through the plugin so everyone gets the same restriction, and put the reason in the agent description, because a person reading the list of agents should understand why the reviewer cannot generate. Review the tool names whenever Sume's registry changes: the docs say live ids are underscore names and that tools_list is the contract, and a renamed or new paid tool is not covered by an old deny list. An allowlist in tools is the safer half of the pair, since anything new is excluded by default.

If your organization manages settings centrally, check how plugin agents interact with managed rules before assuming either wins; the related post on managed permission rules covers one such case. Keep a short test script of prompts that should be refused, and run it after each Claude Code update, since agent behavior has been changing across the 2.1.28x releases, including permission-mode inheritance for subagents.

Last, keep the human in the loop for the first paid call of any new plugin. A plugin install is code from someone, and a preview with dry_run costs nothing and shows what it would do.