Cross-session teammate/subagent messages leak between unrelated Claude Code sessions

Summary

When multiple independent Claude Code sessions each spawn teammates/subagents (via Agent/TeamCreate) at the same time — e.g. running separate multi-agent pipelines in separate terminals for unrelated tasks — completion notifications and messages from one session's teammates are delivered into a completely unrelated session. The messages are not filtered by originating session/team, so a session working on an unrelated task starts receiving "Teammate finished" notifications and forwarded messages that have nothing to do with what it's doing.

Environment

• Claude Code CLI, multiple concurrent terminal sessions on the same machine
• Each session running its own multi-agent pipeline (custom skills/prompts that call Agent(..., team_name=...) to spawn background teammates, e.g. a static-analysis agent, a code-review agent, etc.)
• Two (or more) sessions running different pipelines on different projects/tasks at the same time

Observed behavior

Terminal transcript shows a session that is actively working on one task (reviewing a pull request) receiving a stream of unrelated messages, roughly of this shape:

Message from teammate `<task-1>-static-analysis` (ctrl+o to expand)
Teammate `<task-1>-static-analysis` finished
Message from teammate `<task-1>-code-review` (ctrl+o to expand)
Teammate `<task-1>-code-review` finished
Message from teammate `<task-2>-static` (ctrl+o to expand)
Teammate `<task-2>-static` finished
Message from teammate `<task-2>-specific-check` (ctrl+o to expand)
Teammate `<task-2>-specific-check` finished
Message from teammate `<task-2>-codereview` (ctrl+o to expand)
Teammate `<task-2>-codereview` finished

None of these teammates belong to the receiving session's own pipeline/task — they belong to at least one other session's pipeline, running concurrently in a different terminal on a completely different piece of work.

The receiving session correctly identified these as noise and ignored them, but this required manual reasoning each time, and there is no guarantee a pipeline won't misinterpret an unrelated "finished" signal as its own dependency completing (race condition risk), especially in workflows that poll ListAgents for a teammate whose name might coincidentally collide.

Root cause (as best we can tell from tool-level documentation)

1. The Agent tool's team_name parameter is documented as deprecated and ignored: "The session has a single implicit team." So any attempt to scope teammates to a specific task/session via team_name (e.g. TeamCreate(team_name="<task-id>-impl")) has no effect — it's silently a no-op.
2. ListAgents explicitly documents that it lists teammates/agents across all sessions on the machine (and cloud sessions), not just the current session's team: "in-process subagents you spawned, other local Claude sessions on this machine, your Claude sessions running in the cloud..."
3. SendMessage delivers to any agent/session whose name matches, regardless of which session spawned it — there is no session-scoped isolation of the addressable namespace, and per the tool description permission boundaries are per-session but the messaging namespace is not.

Given the above, teammate name collisions or even unrelated teammate broadcasts are visible/routable across sessions that have no logical relationship to each other, purely because they happen to run on the same machine at the same time.

Expected behavior

A teammate/subagent spawned inside session A should only be able to message/notify session A (its actual parent/spawner), never session B, unless session B explicitly addresses that teammate by a fully-qualified, collision-resistant reference. "Session has a single implicit team" should mean the team is scoped to that session, not that all sessions share one global flat namespace of teammates.

Impact

• Confusing/noisy UX: irrelevant "Teammate finished" messages interleave with the user's actual task.
• Latent correctness risk: a pipeline that waits on a teammate name (e.g. polling for "<name>-static finished") could theoretically match a same-named teammate from a different session's pipeline, or at minimum a differently-scoped notification could get mis-attributed.
• No user-facing or prompt-level control exists to suppress or scope this — it was confirmed (by direct inspection of tool schemas) that this is a platform/harness-level routing behavior, not something fixable from a skill's/prompt's own instructions.

Suggested fix

• Make the implicit team genuinely session-scoped: teammates spawned by session A should not appear in session B's ListAgents results, and messages from A's teammates should not be delivered to B, unless B is a designated parent/coordinator of that teammate.
• If cross-session teammate visibility is an intentional feature (e.g. for orchestration across sessions), it should require an explicit opt-in / addressing mechanism, not passive broadcast-by-name-collision.

Workaround currently in use

None available at the skill/prompt level. Users are advised to avoid running multiple multi-agent pipelines concurrently in separate terminals to reduce the chance of confusing cross-talk, but this is a mitigation, not a fix.