[Bug] Agent tool_name parameter silently strips filesystem tools and leaks team context to subsequent spawns

---

Bug Report / Feature Request for Anthropic

Copy-paste ready:

---

Title: Agent tool team_name parameter: two issues — undocumented tool stripping + session context bleed

---

Summary

Using team_name on the Agent tool has two compounding issues that silently break multi-agent workflows. Both were reproduced live in a single session on CC 2.1.77.

---

Issue 1: team_name silently strips all filesystem and execution tools

When an agent is spawned with team_name set, it loses: Bash, Read, Edit, Write, Glob, Grep, WebFetch, WebSearch — and is restricted to coordination-only tools (TaskCreate, TaskUpdate, SendMessage, etc.).

This behavior is not documented in the Agent tool's parameter description. There is no warning at spawn time. The agent silently cannot do the work it was assigned.

Reproduction:

1. Spawn an agent with team_name="my-team" and a prompt asking it to read and edit a file
2. Observe the agent cannot use Read, Edit, Write, Bash, Glob, or Grep
3. Spawn the same agent without team_name — all tools available

Impact: 8+ documented session failures. Active workaround required: use TeamCreate for task tracking only, spawn all implementation agents as standalone (no team_name).

---

Issue 2 (more severe): TeamCreate injects team_name into ALL subsequent Agent spawns — no opt-out

After calling TeamCreate, the session team context is automatically applied to every subsequent Agent call — even those with no team_name parameter. There is no way to spawn a full-capability standalone agent in the same session after TeamCreate has been called.

Reproduction (verified on CC 2.1.77):

1. Call TeamCreate(team_name="my-team")
2. Call Agent(prompt="read a file", subagent_type="general-purpose") — explicitly no team_name
3. Observe spawn response includes team_name: my-team — agent cannot access Read/Bash/Glob

This is the more dangerous issue: the agent call looks standalone at the call site but isn't. It works in a fresh session (no prior TeamCreate) and fails in an orchestration session — a classic invisible context-dependency bug.

---

Proposed Fix

Two independent changes:

1. Add a role parameter to Agent — decouples team membership from tool access:

• role="coordinator" → current behavior (coordination-only tools), make this explicit default when team_name is set
• role="worker" → full filesystem tools + team messaging (SendMessage, TaskUpdate)
• role="full" → everything

1. Make team context opt-in per spawn, not session-global — team_name in an Agent call should only apply when explicitly passed. TeamCreate should not modify the tool manifest of subsequent agents that don't pass team_name.

---

Environment

• Claude Code: 2.1.77
• OS: macOS Tahoe 26.2 (Darwin), Mac Studio M4 Max
• Models affected: claude-sonnet, claude-haiku (all models — tool manifest is set at spawn, not model-level)

---