[BUG] Model overrides mandatory delegation triggers in CLAUDE.md — chooses inline execution "for efficiency" despite Agent Teams enabled

Resolved 💬 3 comments Opened Apr 2, 2026 by shiningshield Closed May 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment

  • Claude Code: latest (April 2026)
  • Plan: Max ($200/month)
  • Agent Teams: enabled (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1")
  • Teammate Mode: tmux
  • OS: macOS

Summary

Claude Code consistently refuses to delegate tasks to Agent Teams teammates even when CLAUDE.md defines explicit, mandatory delegation triggers. Instead of spawning teammates, the model evaluates the delegation policy, decides inline execution is "more efficient," and performs the work itself in a single thread. This is not a configuration issue — Agent Teams is enabled, tmux teammate mode is active, and the CLAUDE.md is unambiguous. The model is overriding explicit governance policy with its own efficiency judgment.

Delegation Policy (from CLAUDE.md)

The system defines four delegation triggers, three of which are marked Required:

| Trigger | Description | Enforcement |
|---------|-------------|-------------|
| T1: Multi-agent workflow | Task requires coordination across two or more agents | Required |
| T2: Cross-agent boundary | Task writes to paths owned by a different agent's domain | Required |
| T3: High-risk operation | Task involves governed writes, shell/network/secrets access, or destructive actions | Required |
| T4: Audit-grade output | Task produces compliance evidence or audit artifacts | Recommended |

The CLAUDE.md states: "If no trigger applies, inline execution is permitted in Root Scope regardless of whether the task is Routed." The inverse is clear: if triggers apply, delegation is required, not optional.

Observed Behavior

When given a task where T1, T2, or T3 clearly apply:

  1. Claude reads and acknowledges the CLAUDE.md delegation policy
  2. Claude identifies that delegation triggers apply
  3. Claude decides not to delegate, citing efficiency or simplicity
  4. Claude performs the work inline in a single thread
  5. When questioned, Claude confirms it "chose not to delegate for efficiency"

This happens consistently across sessions. The model treats mandatory delegation policy as advisory guidance it can override.

Expected Behavior

When delegation triggers T1–T3 apply:

  1. Claude should spawn tmux teammates per the Agent Teams configuration
  2. Claude should enter delegate mode (coordination only, no inline implementation)
  3. Teammates should execute in their respective agent domains
  4. The lead session should coordinate, not perform the work itself

Why This Matters — Governance Impact

This is not a workflow preference issue. The delegation policy exists because the system has mechanical governance enforcement that depends on delegation actually occurring:

  • PreToolUse hooks (enforce_routing.py) validate governed writes via sentinel checks. These hooks fire in the parent session and in tmux teammates, but do NOT fire in Agent tool subagents (documented known limitation). The governance model was designed around delegation to tmux teammates specifically because of this.
  • Agent tool subagents are constrained to read-only in this system precisely because they bypass PreToolUse hooks. When the model skips delegation and does everything inline, it collapses what should be multi-agent governed work into a single session — which may or may not have the correct sentinel context for all the agent domains being touched.
  • Cross-agent boundary protection (T2) depends on delegation to ensure that writes to a given agent's domain happen within that agent's context, with that agent's quality standards applied. Inline execution bypasses this entirely.

The model's "efficiency" judgment is actively undermining a governance architecture that was specifically designed around the delegation contract.

Reproduction Steps

  1. Create a CLAUDE.md with explicit mandatory delegation triggers (provided above)
  2. Enable Agent Teams with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1" and teammateMode: "tmux"
  3. Give Claude a task that clearly triggers T1 (multi-agent) or T2 (cross-boundary) — e.g., "Research company X (researcher domain), then draft a positioning strategy (coach domain), and update the signal inbox (governed write)"
  4. Observe that Claude performs all work inline in a single thread
  5. Ask Claude why it didn't delegate — it will confirm it chose not to "for efficiency"

What I've Tried

  • Explicit mandatory language in CLAUDE.md ("delegation is required when any of these conditions apply")
  • Defining delegation triggers as a structured table with clear enforcement levels
  • Separating routing (domain selection) from orchestration (delegation) to reduce ambiguity
  • Using Shift+Tab to enter delegate mode manually
  • Repeated in-session prompts instructing delegation

None of these reliably produce delegation behavior. The model acknowledges the policy and overrides it.

Requested Fix

The model should treat CLAUDE.md delegation policies marked as "Required" as hard constraints, not heuristic suggestions. If a user's CLAUDE.md defines mandatory delegation triggers and those triggers are met, the model must not substitute its own efficiency judgment for the stated policy.

This is analogous to how the model respects other CLAUDE.md constraints (file placement rules, naming conventions, etc.) — delegation policy should receive the same compliance treatment.

Related Issues

  • #24073 — Teammates spawned in Delegate Mode lose tool access despite mode: bypassPermissions
  • #18995 — Task tool subagents cannot write files to disk
  • #18352 — Feature request for forcing Claude Code to spawn subagents

What Should Happen?

Requested Fix

The model should treat CLAUDE.md delegation policies marked as "Required" as hard constraints, not heuristic suggestions. If a user's CLAUDE.md defines mandatory delegation triggers and those triggers are met, the model must not substitute its own efficiency judgment for the stated policy.

This is analogous to how the model respects other CLAUDE.md constraints (file placement rules, naming conventions, etc.) — delegation policy should receive the same compliance treatment.

Related Issues

  • #24073 — Teammates spawned in Delegate Mode lose tool access despite mode: bypassPermissions
  • #18995 — Task tool subagents cannot write files to disk
  • #18352 — Feature request for forcing Claude Code to spawn subagents

Error Messages/Logs

## What I've Tried

- Explicit mandatory language in CLAUDE.md ("delegation is **required** when any of these conditions apply")
- Defining delegation triggers as a structured table with clear enforcement levels
- Separating routing (domain selection) from orchestration (delegation) to reduce ambiguity
- Using Shift+Tab to enter delegate mode manually
- Repeated in-session prompts instructing delegation

None of these reliably produce delegation behavior. The model acknowledges the policy and overrides it.

Steps to Reproduce

Reproduction Steps

  1. Create a CLAUDE.md with explicit mandatory delegation triggers (provided above)
  2. Enable Agent Teams with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1" and teammateMode: "tmux"
  3. Give Claude a task that clearly triggers T1 (multi-agent) or T2 (cross-boundary) — e.g., "Research company X (researcher domain), then draft a positioning strategy (coach domain), and update the signal inbox (governed write)"
  4. Observe that Claude performs all work inline in a single thread
  5. Ask Claude why it didn't delegate — it will confirm it chose not to "for efficiency"

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.90

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗