The following comment was made by an LLM, it may be inaccurate:

Summary:

One potentially related PR found:

• Add context control for subagents #4119 - Add context control for subagents (Add context control for subagents #4119)

This addresses similar concerns around managing which subagents are included in context. Review it to ensure there's no duplicate effort or conflicting approaches.

Thanks for flagging #4119! After reviewing, these PRs address different problems:

#4119 optimizes the context sent to subagents when they're invoked.
#7271 optimizes the task tool's description in the system prompt (before any subagent is invoked).

They're complementary - both reduce token usage but at different points:

• This PR reduces tokens in the system prompt (affects every message)
• Add context control for subagents #4119 reduces tokens in subagent invocations (affects runtime)

With 150 subagents, the task tool description alone adds ~6-10k tokens to every conversation's system prompt. This PR allows agents to specify which subagents they need, reducing that overhead.

To let you know any subagent that you list as denied in the task tool using the new permission system is already hidden from the task tool. The functionality that you are proposing already exists, just use the new permission system

Thanks @malhashemi! I tested the permission.task approach and confirmed it works as you described.

However, I'd like to make the case that the allowlist approach is significantly more ergonomic for real-world usage at scale.

Real-World Numbers

Our setup (aidevops):

• 14 primary agents (SEO, Accounts, Build+, Content, etc.)
• 177 subagents (and growing rapidly)
• Each primary agent needs only 5-20 relevant subagents

Config Comparison

Deny-list (current) - Accounts agent needing only quickfile:

"permission": {
  "external_directory": "allow",
  "task": {
    "*": "deny",
    "quickfile": "allow"
  }
}

Allowlist (proposed):

"subagents": ["quickfile"]

For Build+ needing ~20 subagents, the deny-list becomes:

"task": {
  "*": "deny",
  "code-standards": "allow",
  "code-simplifier": "allow",
  "best-practices": "allow",
  "git-workflow": "allow",
  "branch": "allow",
  "preflight": "allow",
  "postflight": "allow",
  "release": "allow",
  "version-bump": "allow",
  "conversation-starter": "allow",
  "osgrep": "allow",
  "augment-context-engine": "allow",
  "context-builder": "allow",
  "context7": "allow",
  "toon": "allow",
  "playwright": "allow",
  "stagehand": "allow",
  "github-cli": "allow",
  "coolify": "allow"
}

vs:

"subagents": ["code-standards", "code-simplifier", "best-practices", "git-workflow", "branch", "preflight", "postflight", "release", "version-bump", "conversation-starter", "osgrep", "augment-context-engine", "context-builder", "context7", "toon", "playwright", "stagehand", "github-cli", "coolify"]

Why Allowlist is Better

Proposal

The subagents field could be syntactic sugar that internally generates permission.task rules. This:

• Keeps the permission system as the source of truth
• Provides a cleaner DX for the common "allowlist" case
• Is fully backward compatible

Happy to revise the implementation if there's interest from maintainers. @rekram1-node @thdxr thoughts?