Agent teams: task self-claim has no role/tool-compatibility filter, so read-only teammates claim tasks they cannot do

Status Open
Reported on v2.1.268
Maintainer reply None cached
Activity 0 comments · opened Sep 11, 2026

What happens

In an agent team with role-typed teammates, self-claim matches on availability only. Per https://code.claude.com/docs/en/agent-teams:

Self-claim: after finishing a task, a teammate picks up the next unassigned, unblocked task on its own
Task claiming uses file locking to prevent race conditions when multiple teammates try to claim the same task simultaneously.

The lock prevents two teammates claiming the same task. Nothing prevents the wrong teammate claiming a task. A teammate spawned from a subagent definition whose tools list excludes Write and Edit will still self-claim an implementation task, start it, and fail — it physically cannot produce the deliverable. The lead then has to notice and manually reassign, and the bounce repeats each time a dependency completes and frees more unassigned tasks.

Reproduction

  1. Enable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
  2. Define two subagents: builder with tools: Read, Write, Edit, Bash, and reviewer with tools: Read, Bash (deliberately no Write/Edit).
  3. Spawn both as named teammates.
  4. TaskCreate several implementation tasks and leave them unassigned.
  5. Let reviewer go idle.

Observed: reviewer self-claims an implementation task and cannot complete it.
Expected: a teammate that cannot perform a task does not claim it.

We hit this during an internal dogfood of a 5-role team (lead + 3 implementers + 1 read-only reviewer): the read-only reviewer claimed implementation tasks until the lead manually reassigned all 14 to the implementer.

Current workaround

Pre-assign every task at creation — TaskCreate followed immediately by TaskUpdate({owner}), since TaskCreate does not accept owner — and set blockedBy on review tasks so they cannot be claimed early. This covers the common case but is fragile: any task added mid-run without an explicit owner is immediately claimable by any idle teammate, and the burden of never leaving a task unassigned falls on prompt discipline.

Proposed fix (any one of these would close it)

  1. Task-level capability metadata — an optional field (e.g. requiredTools: ["Write", "Edit"] or requiredAgentType) that self-claim matches against the claiming teammate's resolved tool set.
  2. Per-teammate self-claim filter at spawn time — e.g. selfClaim: { allowAgentTypes: ["builder"] }.
  3. noSelfClaim: true teammate mode — disables self-claim for that teammate entirely, so it only works tasks the lead explicitly assigns. Simplest of the three and sufficient for our case.

Option 3 alone would resolve this for role-typed teams without introducing a new matching semantics surface.

Environment

  • Claude Code 2.1.268, macOS (Darwin 25.6.0)
  • Originally observed on 2.1.143; re-verified against the current docs and 2.1.268 on 2026-09-11.

View original on GitHub ↗