Task tool: broken delegation chain — orchestrator cannot supervise its own agents
Problem
The Task tool breaks the delegation chain. In a correct architecture:
User → Orchestrator → Agent
Each level supervises the one below it. The orchestrator dispatches agents, approves/denies their tool calls, and returns results to the user. The user only interacts with the orchestrator.
What actually happens: Agent tool calls bypass the orchestrator and go directly to the user for approval. The orchestrator has no approval/denial authority over its own agents. The user is forced into a supervisory role they don't have context for — they see bare commands with no indication of which agent triggered them or why.
Why this is the root cause
Five open issues describe symptoms of this single architectural break:
- #14118 — Agent transcripts leak into parent context (94% bloat). The orchestrator receives raw transcripts instead of structured results because there's no supervisory layer to filter them.
- #10906 — Subagents ignore parent permission settings (200+ daily prompts). Permissions bypass the orchestrator entirely.
- #16424 — No agent identification in hook payloads. The user can't tell which agent triggered a prompt because the system wasn't designed for users to interact with agents directly.
- #18924 — Feature request for "step-into" mode. Users want orchestrator-level visibility because they're forced into a role the orchestrator should fill.
- #21460 — PreToolUse hooks bypass via subagents. Security boundaries only apply to the orchestrator, not its agents, because agents operate outside the supervisory chain.
Each of these would be resolved or significantly mitigated by restoring the delegation chain — giving the orchestrator supervisory authority over agent tool calls.
Expected behavior
- Agent tool calls route through the orchestrator, not directly to the user
- The orchestrator can approve, deny, or filter agent tool calls based on its context
- The user only sees orchestrator-level actions and results
- Permission settings and hooks apply transitively through the chain
No viable workaround exists
The delegation boundary cannot be reconstructed at the user level. The user cannot reliably distinguish agent permission prompts from orchestrator permission prompts — there is no agent identification in the prompt UI (#16424). Instructing agents "do not use Bash" via prompt text is a soft constraint with no enforcement mechanism. The architectural gap requires an architectural fix.
Environment
- Claude Code CLI
- macOS
- Workflow: dispatching 6+ parallel Task agents for content generation
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗