Team agent tool calls blocked: permission approval requests never reach team lead

Summary

When teammate agents in Agent Teams need tool permission approval, the "Waiting for team lead approval" prompt blocks indefinitely. The approval request is supposedly sent to the team lead, but it never arrives as an actionable message — the team lead has no way to approve or deny it. This blocks ALL tool calls (Read, Bash, Grep, Glob — not just MCP tools).

Environment

• Claude Code version: latest (as of 2026-03-02)
• macOS 15.4 (Darwin 25.3.0)
• Model: claude-opus-4-6
• Using cmux for team agent management (tmux-based)
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Note: This issue was self-reported by Claude (Opus) during a manuscript validation task. Claude encountered the blocking behavior, documented it, and was asked by the user to file this issue.

Steps to Reproduce

1. Create a team and spawn a teammate agent:

TeamCreate(team_name="my-team")

Agent(
  name="researcher",
  subagent_type="general-purpose",
  team_name="my-team",
  run_in_background=True,
  prompt="Read the file /tmp/test.txt and report its contents"
)

1. The teammate agent attempts to call Read (or any tool)
2. The agent shows: "Permission request sent to team 'my-team' leader" and hangs
3. The team lead never receives this permission request as an actionable message
4. The agent blocks indefinitely

Expected Behavior

Either:

• The permission request should arrive to the team lead as an actionable message (like SendMessage) that the lead can approve/deny
• Or standard tools (Read, Grep, Glob, Bash) should not require team lead approval when the user has already authorized them in their session/settings

Observed Behavior

• The teammate agent shows "Waiting for team lead approval" for every tool call
• The approval request does not arrive in the team lead's conversation as a message
• The team lead has no mechanism to approve the pending request
• The mode parameter passed to Agent() (e.g., mode: "bypassPermissions") is ignored — the CLI always launches with --permission-mode acceptEdits
• The team_name from the active team context is always injected into the agent CLI invocation, even when omitted from Agent()

Additional Findings

mode parameter on Agent() is ignored

When spawning a teammate with mode: "bypassPermissions", the actual CLI invocation still uses --permission-mode acceptEdits:

claude --agent-id researcher@my-team \
       --agent-name researcher \
       --team-name my-team \
       --permission-mode acceptEdits \    # ← NOT bypassPermissions
       --model claude-opus-4-6

No workaround when a team is active

• Omitting team_name from Agent() doesn't help — the active team context is auto-injected
• mode: "bypassPermissions" doesn't help — it's overridden to acceptEdits
• permissions.allow in settings.json doesn't help — team lead approval is a separate layer
• The only option is to not use Agent Teams at all

Intermittent behavior across sessions

In one session, teammate agents could use Read/Grep/Glob without issues. After restarting Claude Code and resuming the same team, ALL tools required team lead approval. This suggests the approval gate behavior may change between sessions or depend on initialization order.

Context

This was encountered while running a manuscript validation team (via cmux) where multiple agents needed to:

• Read manuscript files (LaTeX, BibTeX)
• Run Bash commands to verify compilation
• Fetch web content to validate bibliography entries

All agents got stuck on "Waiting for team lead approval" and had to be killed. The work had to be done sequentially by the main session instead.

Impact

• Agent Teams are effectively unusable when teammates need any tool permissions
• Defeats the purpose of parallel agent work
• Forces all work through the main session sequentially
• The mode parameter being ignored means there's no escape hatch

Related Issues

• #27099 — allowed-tools: silently ignored in agent frontmatter
• #23415 — Agent Teams: Teammates don't poll inbox — messages never delivered
• #23506 — Custom agents cannot spawn subagents into teams

---

🤖 This issue was reported by Claude (Opus 4.6) and filed at the user's request. The bug was encountered and documented during an actual workflow, not constructed as a test case.