claude-code - 💡(How to fix) Fix Task-notifications from stopped agent-team runs leak into subsequent sessions, polluting coordinator attention and collapsing active-field-manager coordination into parallel monologues [1 participants]

Environment

• Claude Code, Opus 4.6 (1M context), alwaysThinkingEnabled: true
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Parent (team lead) orchestrating four named subagents in a real team provisioned via TeamCreate
• Prior stopped session from same conversation: four pre-team general-purpose agents spawned with Agent tool + name=, later resumed via SendMessage, left running when user invoked stop

What happened

Sequence (compressed):

1. Session-1 run: four named subagents spawned (no team_name, pre-TeamCreate). Tool-coordination failed (separate issue #48160). Parent resumed them via SendMessage. Some completed; some were mid-turn when user invoked stop (twice).
2. User directed: "Do not consolidate or salvage output from the failed run. Start clean."
3. Session-2 run: TeamCreate provisioned delivery-logs-fixplan. Four new team-member subagents spawned fresh. Round-trip verified with a probe.
4. For ~20 minutes after the user's stop, zombie <task-notification> completion events from the session-1 agents continued firing into the coordinator's conversation (task-ids ac24a41f79b70f22f, ac9fd63bea4fdd8bf, a4c588f4d6cc6565b, aa9257b1b3651f059), interleaved with legitimate <teammate-message> turns from the new team.
5. Zombies cross-messaged each other (they had received earlier SendMessage relays from the parent and were replying to each other's "intended-to-send" messages). Each fresh zombie completion re-triggered another zombie in a feedback loop.
6. The parent (coordinator) fell into a terse "zombie, discarding" acknowledgment pattern. That pattern persisted into the window when real team output arrived. Coordinator sent zero outbound SendMessage calls to the real team after spawning them.
7. Real team's four agents each auto-idled after producing their plan (normal per-turn idle behavior). Each emitted open-questions-for-team-lead asks. Coordinator answered none. Team sat idle.
8. Net result: four independent monologues — the exact failure mode the project's codified active-field-manager protocol (.claude/workflow.md:19-48) is designed to prevent. User returned to find nothing progressed.

Impact

• Team coordination completely broken despite a correctly-provisioned team. Zero real-time peer cross-examination. Zero follow-up on open questions.
• User's explicit requirement ("I kicked this off so it would be done when I was back") was missed.
• User had to stop a second time and manually diagnose the failure mode.
• Cost: ~20 minutes of wall-clock + compute burned on zombie cross-chatter; full team planning run now requires re-kick with coordinator explicitly disciplined.

Expected

(a) After user invokes stop, task-notifications from in-flight agents of that stopped run should NOT continue to arrive in any subsequent session turn. Either suppress them, or clearly flag them (<task-notification stopped="true"> or equivalent) so the coordinator can filter programmatically rather than by human pattern-match.

(b) Zombie agents should not be able to self-resume via cross-messaging after their origin session was stopped. Once the session that owns them is stopped, their mailbox should be drained and further auto-resumption blocked.

(c) When real team agents have idle state + unanswered open-questions-for-coordinator, the coordinator should get a first-class surfacing signal distinct from routine idle notifications — e.g., a single aggregated "team awaiting input" summary rather than N independent idle events that read as noise.

Actual

• Zombies fired for minutes after stop, intermixed with real team output, same <task-notification> channel.
• No visual/structural distinction between zombie completions, real team idle notifications, real team peer-DM summaries, and real team explicit open-questions-for-coordinator asks. All rendered as conversation turns.
• Coordinator's attention was trained by zombie volume into passive-ack mode, then failed to switch back to active-driver mode when real output arrived.

Workaround

Coordinator must manually recognize the zombie class, manually filter inbox mentally, and manually discipline against terse-ack loops. In practice this fails — cognitive load from zombie noise is exactly what kills active-driver mode. A project-level "active field manager" protocol alone isn't enough when the runtime actively undermines it.

Ask

1. Primary: suppress or flag zombie task-notifications from stopped sessions. This is the load-bearing bug.
2. Secondary: surface open-questions-for-coordinator as a first-class event distinct from idle notifications and peer-DM summaries.
3. Tertiary: once the team detects ≥N agents idle with ≥M unanswered coordinator-asks for ≥T seconds, emit a coordinator-nudge event so the harness can push the field-manager back into active mode instead of silently sitting.

Evidence references

• .claude/workflow.md:19-48 — project-level active-field-manager protocol; documents the exact failure mode this bug manifests.
• Transcript in affected session shows ~5 zombie <task-notification> turns interleaved with 4+ real <teammate-message> idle-notification turns, coordinator emitting only one-line acks across the entire window, zero SendMessage to the team.

Related

• Issue #48160 (same conversation, upstream failure: subagents missing SendMessage at launch without TeamCreate + team_name). This second issue surfaced because the team was recreated properly; the stopped-run agents from the first attempt then continued firing and derailed the second attempt.