Agent teams: idle-notification ping-pong — acknowledging a finished teammate wakes it and emits another idle_notification

Description

When using named subagents / agent teams, a teammate that has delivered its final report stays resident and emits an idle_notification each time it finishes a turn. This creates a wasteful ping-pong:

1. Teammate finishes its task and sends its final report → idle_notification #1.
2. The lead session reviews the work and sends a short courtesy acknowledgment ("thanks, all done, nothing further").
3. That message wakes the teammate, which processes it, has nothing to do, and goes idle again → idle_notification #2 (sometimes #3).
4. Each notification triggers a new turn in the lead session, which reads it and typically tells the user "that was just an idle notification".

Net effect: up to three "I'm done" style notifications per agent, extra tokens burned on both sides (teammate wake-up + lead re-reads), and noise for the user, who perceives it as the agent repeatedly reporting completion.

Expected behavior / suggestions

Any of these would remove the ping-pong:

• Dedupe idle notifications: suppress an idle_notification when nothing about the teammate's state changed since the last one (no new task, no meaningful output — it merely processed an acknowledgment).
• A lightweight "release/ack" send option that delivers a message to the teammate's transcript without waking it for a full turn.
• Docs guidance: make it explicit that after accepting a teammate's final report the lead should either stay silent or send a formal shutdown_request — a plain-text farewell is an anti-pattern that re-triggers the loop. (We only discovered this by observing the token waste.)

Keeping the teammate resident is otherwise great (it can be resumed with context later) — only the notification loop needs fixing.

Environment

• Claude Code CLI on Windows 11 (PowerShell), current release
• Agent teams / named subagents (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), spawned via the Agent tool with name:, communicating via SendMessage