[BUG] Agent teams: one teammate message or idle_notification is delivered to the lead up to 4 times with an identical timestamp (successor to #74112, stale-closed)

Preflight Checklist

• [x] I have searched existing issues, including closed ones (searched: "duplicate idle_notification", "duplicate teammate message", "idle notification flood", "teammate message delivered twice", "agent team duplicate delivery", "mailbox duplicate delivery")
• [x] This is a single bug report
• [x] I am using a current version of Claude Code (2.1.260; 2.1.261 is the newest published)

What's Wrong?

In agent teams, a lead session spawns named background teammates and they report back with SendMessage. Each incoming teammate message wakes the lead for a full turn. The bug is that one message event is handed to the lead more than once: the same report body arrives byte-identical several times, and the same idle_notification arrives several times carrying the identical timestamp field, which is what makes it one event redelivered rather than several events generated.

Both shapes cost a lead turn per copy. The lead has to read the copy, recognise it as already-processed content, and discard it. Across a long orchestration session that is a dozen or more wasted lead invocations, each of which also carries the risk that a duplicate of a side-effecting request is not recognised as a duplicate and is acted on twice.

This is the successor to #74112, which described the idle_notification half of this and was auto-closed as stale on 2026-09-04 with no fix and no maintainer response. The closing note asks for a new issue if it is still relevant. It is still relevant, and at higher multiplicity than when it was filed.

Not a duplicate of the open neighbours. The discriminator is whether the duplicate copies carry the same event identity.

• #47930 (lead loops on idle notifications and duplicate task_assignment echoes) is about the volume of distinct notifications waking the lead. Its own sample trace carries three different timestamps (12:37:38.194Z, 12:37:58.164Z, 12:38:00.473Z), so each of those is a real separate event.
• #85047 (idle-notification ping-pong) is about generating a new idle notification, because acknowledging a finished teammate wakes it and it goes idle again.
• #77595 (now also stale-closed) is sender-side duplication of the body inside a single call, into invented content and routing.content fields.

This report is none of those. The copies here are the same delivery, same body, same timestamp value, replayed to the lead N times. Deduplicating on (sender, message id or timestamp) before the delivery wakes the lead would fix this one and would not fix any of the three above.

What Should Happen?

One event, one delivery to the lead.

1. Deduplicate deliveries by (sender, message id), or by (sender, timestamp) where no id exists, before the delivery is surfaced as a fresh lead turn. A message the lead has already been handed is never handed to it again.
2. Collapse idle notifications from a teammate with no pending work down to at most one delivery.
3. Give the sender a reliable delivered signal. One teammate below re-sent its entire report by hand because it could not tell whether its first send had landed, which turns a delivery-layer defect into extra duplicate traffic from the sender side too.

Error Messages/Logs

There is no error. The waste is silent. Sanitised shapes, teammate names replaced, timestamps kept verbatim because they are the evidence:

# One turn, one event, four copies. Note the identical timestamp on all four.
<teammate-message teammate_id="teammate-A">
{"type":"idle_notification","from":"teammate-A","timestamp":"2026-09-01T14:53:46.574Z","idleReason":"available"}
</teammate-message>
<teammate-message teammate_id="teammate-A">
{"type":"idle_notification","from":"teammate-A","timestamp":"2026-09-01T14:53:46.574Z","idleReason":"available"}
</teammate-message>
<teammate-message teammate_id="teammate-A">
{"type":"idle_notification","from":"teammate-A","timestamp":"2026-09-01T14:53:46.574Z","idleReason":"available"}
</teammate-message>
<teammate-message teammate_id="teammate-A">
{"type":"idle_notification","from":"teammate-A","timestamp":"2026-09-01T14:53:46.574Z","idleReason":"available"}
</teammate-message>

# The earlier, two-copy form of the same signature, from 2026-07-17:
{"idleReason":"available","timestamp":"2026-07-17T23:57:58.237Z"}
{"idleReason":"available","timestamp":"2026-07-17T23:57:58.237Z"}

Dated occurrences, four sessions, two platforms of report.

| Date | Version | What was delivered more than once |
|---|---|---|
| 2026-07-17/18 | 2.1.218 | Two copies of one idle_notification with timestamp 23:57:58.237Z in a single delivery, then that same timestamp redelivered again in a later turn. Substantive teammate reports arrived 2 to 3 times, byte-identical: a verdict-bearing report delivered, then redelivered as a fresh turn minutes later; another teammate's report delivered twice back to back. One finished teammate produced roughly 10 idle-echo turns after its work was complete and acknowledged, including after an explicit instruction to stop sending notifications. |
| 2026-07-23 | 2.1.218 | In one 6-teammate fan-out: one teammate's full final report, several thousand tokens, delivered twice in separate lead turns. A second teammate's idle_notification delivered twice with the identical timestamp 05:51:09.301Z. A third teammate re-sent its full report manually because it had no way to tell its first send had landed, and its re-send note cited the original message id as already delivered. |
| 2026-09-01/02 | at most 2.1.252 | A completion report from teammate-B, roughly 4KB, delivered 3 times verbatim in one lead turn. An idle_notification from teammate-A with the identical timestamp 2026-09-01T14:53:46.574Z delivered 4 times in a single turn. The 3x report delivery alone cost roughly 12KB of lead context for one message. |

One part of the 2026-09-01 occurrence is probably by design, and is called out here so it is not confused with the bug. Alongside the three verbatim copies, a fourth copy of that same report arrived re-wrapped as an idle_notification payload. 2.1.251 changed a teammate's final answer to ride inside the idle notification rather than a content-free "available" notice, so that fourth rendering looks like the intended new behaviour, not a redelivery. It does sharpen the cost of the bug, though: each duplicated idle_notification now carries a full report body instead of a 100-byte ping, so the same duplication multiplier is applied to a much larger payload.

Version bound, stated so it is not over-claimed. The 2.1.212 fix for "a stopping teammate could send the leader duplicate idle notifications when team initialization re-ran within a session" predates the 2.1.218 occurrences, so it does not cover this. The most recent occurrence happened at 2026-09-01T14:53Z, when 2.1.252 was the newest published release, so it ran on 2.1.252 or older. The 2.1.257 fix for "a teammate permission request being answered twice when the leader's mailbox write was briefly locked" published later that day and is the nearest thing in the same layer, but it is scoped to permission requests rather than report or idle delivery, and no occurrence has yet been observed on 2.1.257 or newer. If that mailbox-lock fix does happen to cover this class, this issue can be closed on that basis; the reason for filing is that nothing in 2.1.213 through 2.1.261 claims to deduplicate teammate message or idle notification delivery.

Steps to Reproduce

1. Enable agent teams (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) and, from a lead session, spawn 4 to 8 named background teammates with the Agent tool, each given a unit of work to complete and report on with SendMessage.
2. Keep working in the lead session while they run, and exchange at least one follow-up round trip with a teammate after its first report, which is the condition under which the duplication becomes frequent.
3. Let the teammates finish and go idle. Do not shut them down.
4. Read the lead's incoming teammate messages, in the transcript JSONL under ~/.claude/projects rather than by eye, and group them by (from, timestamp). Any group with more than one member is a redelivery. Also compare consecutive report bodies for byte equality.

Frequency: it does not fire on every message, but it reproduces routinely in any session with several teammates and follow-up round trips, and the number of duplicates grows with session length and with the number of lead-to-teammate re-pings. It has been present continuously across 2.1.218 to 2.1.252 in our sessions.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Version

2.1.260 (occurrences above observed on 2.1.218 and on at most 2.1.252)

Platform

Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Reported from an automated multi-agent development harness that runs unattended, so every redelivered message is a lead invocation nobody is present to discard cheaply. The same symptom was reported independently on Windows in #74112, which suggests this is not platform-specific; #74112 was labelled platform:windows from its original reporter, and the occurrences above are all Linux.

Related, all open, all distinct root causes as set out above: #47930, #85047, #82858, #76500.