You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After teammates complete tasks and go idle, the lead agent has no mechanism to distinguish idle-but-alive teammates from dead/crashed teammates. Both display identically (grey) in the UI. The lead cannot determine which teammates are reachable, so it spawns duplicate agents with "-2" suffixes — permanently destroying the original agent's accumulated context.
This is particularly damaging for knowledge-intensive workflows where agents accumulate domain context (Jira queries, analysis, file reads) over a session and need to be available for follow-up work.
Four Independent Issues
1. No visual or programmatic distinction between idle and dead agents
Idle agents (process alive, waiting for messages) and dead agents (process gone from prior session) both render as "grey" in the in-process UI. There is:
No color difference (e.g., amber/dim for idle vs grey/strikethrough for dead)
No isTeammateAlive() or getTeammateStatus() tool
No process liveness check injected into the lead's context
No way for the lead LLM to determine which teammates are reachable
The docs state "idle teammates can receive messages" but the lead has no way to KNOW a teammate is idle vs dead. The TeammateIdle hook addresses whether agents GO idle, but doesn't help the lead distinguish idle from dead after the fact.
Expected: Lead should be able to determine teammate liveness before deciding to spawn vs message.
2. Memory GC destroys team membership records (v2.1.47 / v2.1.50 / v2.1.59 regression)
Three changelog entries progressively garbage-collect the lead's evidence that teammates exist:
v2.1.47: "Improved memory usage by trimming agent task message history after tasks complete" + "releasing API stream buffers, agent context, and skill state after use"
v2.1.50: "Fixed memory leak where completed teammate tasks were never garbage collected from session state"
v2.1.59: "Improved memory usage in multi-agent sessions by releasing completed subagent task state"
The GC doesn't distinguish "task content" (100MB, safe to GC) from "team membership records" (2KB, must never be GC'd). After GC, the lead forgets teammates exist — even if they're still alive and idle.
The memory leak fix was needed (#23239: 4.4GB in 17 minutes), but it's over-aggressive. Team membership records should be exempt from GC.
Expected: GC should clean up task output content while preserving team membership metadata.
3. Team config not preserved across context compaction (#23620)
When the lead's context window fills and compaction triggers, team membership information is lost. CLAUDE.md is re-injected after compaction. Team config is not. This has been open as #23620 since Feb 6, 2026 with 7 thumbs up.
Expected: Team config should be treated like CLAUDE.md and re-injected after compaction.
4. SendMessage creates orphan inboxes without recipient validation (#25135)
SendMessage with a non-existent recipient name silently creates an inbox file and "delivers" the message to a file nobody polls. No error, no warning. Messages are permanently lost.
In our case, agents were instructed to message "product-mgmt" but the lead's config name was "team-lead". 14 agent messages were silently delivered to product-mgmt.json — a file the lead never reads.
Expected: SendMessage should validate recipient names against the team config and return an error for unknown recipients.
Create a team, spawn 5 teammates, let them complete tasks and go idle
All teammates show as "grey" in in-process mode
End the session (Ctrl+C or close terminal)
Start a new session, create the same team name
config.json now has 10 members: 5 dead from prior session + 5 new with "-2" suffixes
All 10 show identically as grey — humans and LLM cannot distinguish alive from dead
Send a message to one of the "-2" agents → it responds (proving it's alive)
Send a message to one of the original agents → no response ever (dead process)
Lead has no way to determine this without trial-and-error messaging
Live Evidence
Our config.json contained 11 members: 5 dead processes from yesterday's session and 5 alive-but-idle "-2" agents from today. All displayed identically. The lead spawned duplicates because it couldn't tell which were reachable.
We proved an idle agent was alive by sending it a test message — it responded immediately. But the lead had no programmatic way to discover this.
Impact
Knowledge-intensive multi-agent workflows (our use case: 5 domain-specific Jira analysts + 1 PM synthesizer) become unusable
Every task completion → grey-out → lead spawns duplicate → original context destroyed
The TeammateIdle hook mitigates idle timing but does NOT address the lead's inability to distinguish idle from dead
Environment
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1Bug Description
After teammates complete tasks and go idle, the lead agent has no mechanism to distinguish idle-but-alive teammates from dead/crashed teammates. Both display identically (grey) in the UI. The lead cannot determine which teammates are reachable, so it spawns duplicate agents with "-2" suffixes — permanently destroying the original agent's accumulated context.
This is particularly damaging for knowledge-intensive workflows where agents accumulate domain context (Jira queries, analysis, file reads) over a session and need to be available for follow-up work.
Four Independent Issues
1. No visual or programmatic distinction between idle and dead agents
Idle agents (process alive, waiting for messages) and dead agents (process gone from prior session) both render as "grey" in the in-process UI. There is:
isTeammateAlive()orgetTeammateStatus()toolThe docs state "idle teammates can receive messages" but the lead has no way to KNOW a teammate is idle vs dead. The TeammateIdle hook addresses whether agents GO idle, but doesn't help the lead distinguish idle from dead after the fact.
Expected: Lead should be able to determine teammate liveness before deciding to spawn vs message.
2. Memory GC destroys team membership records (v2.1.47 / v2.1.50 / v2.1.59 regression)
Three changelog entries progressively garbage-collect the lead's evidence that teammates exist:
The GC doesn't distinguish "task content" (100MB, safe to GC) from "team membership records" (2KB, must never be GC'd). After GC, the lead forgets teammates exist — even if they're still alive and idle.
The memory leak fix was needed (#23239: 4.4GB in 17 minutes), but it's over-aggressive. Team membership records should be exempt from GC.
Expected: GC should clean up task output content while preserving team membership metadata.
3. Team config not preserved across context compaction (#23620)
When the lead's context window fills and compaction triggers, team membership information is lost. CLAUDE.md is re-injected after compaction. Team config is not. This has been open as #23620 since Feb 6, 2026 with 7 thumbs up.
Expected: Team config should be treated like CLAUDE.md and re-injected after compaction.
4. SendMessage creates orphan inboxes without recipient validation (#25135)
SendMessagewith a non-existent recipient name silently creates an inbox file and "delivers" the message to a file nobody polls. No error, no warning. Messages are permanently lost.In our case, agents were instructed to message "product-mgmt" but the lead's config name was "team-lead". 14 agent messages were silently delivered to
product-mgmt.json— a file the lead never reads.Expected: SendMessage should validate recipient names against the team config and return an error for unknown recipients.
Reproduction Steps (Issue 1 — idle vs dead)
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1Live Evidence
Our
config.jsoncontained 11 members: 5 dead processes from yesterday's session and 5 alive-but-idle "-2" agents from today. All displayed identically. The lead spawned duplicates because it couldn't tell which were reachable.We proved an idle agent was alive by sending it a test message — it responded immediately. But the lead had no programmatic way to discover this.
Impact
Related Issues
Proposed Fixes