[BUG] Teammate pane silent crash + ghost statusline chips (v2.1.116 / darwin arm64 / tmux)

Summary

Persistent teammate pane crash + in-memory sub-agent handle leak on claude-code v2.1.116 / macOS arm64 / tmux. Reporting as a fresh issue because the three previous reports on similar symptoms (#8978, #8722, #8829) are closed as not-planned and locked to new comments; the behavior is still occurring on the current release, so we'd like to surface updated repro data in case it's actionable.

Environment

• Claude Code CLI v2.1.116
• macOS darwin 25.4.0 (arm64, Apple Silicon)
• tmux 3.5a
• Orchestration pattern: one Lead claude pane spawning multiple teammate Agent({ team_name, name, ... }) panes in the same tmux session
• Node v22 (installed via Homebrew)

Symptom 1 — Silent teammate pane crash during long tasks (related: #8978, #8829)

Repro (most reliable):

1. From Lead, spawn three teammates in a single turn, each sent a ~400-line / 8-file diff to review:

``
Agent({ team_name: T, name: "raider", ..., run_in_background: true })
Agent({ team_name: T, name: "inspector", ..., run_in_background: true })
Agent({ team_name: T, name: "sentinel", ..., run_in_background: true })
``

1. One of the three panes silently exits mid-turn. Pane returns to zsh, leaving the line Resume this session with: claude --resume <uuid>. No error message in the pane.
2. Surviving teammates continue until they attempt SendMessage to the Lead; the dropped teammate never reports.
3. Running claude --resume <uuid> in that pane sometimes re-enters the crash loop reported in #8978.

Observed frequency on our setup:

| Concurrency | Crash rate (at least one pane lost) |
|---|---|
| 3 parallel teammates, large diff | ~25% |
| 2 parallel | ~5% |
| 1-at-a-time sequential | not observed |

Also reliable on single-teammate runs once the implementation step exceeds ~20 minutes of sustained Edit/Write activity.

Symptom 2 — Ghost statusline chips after teammate completion (related: #8722)

Repro:

1. Run a 2-hour session that spawns and completes ≥10 teammates (any mix of review + implementation roles).
2. As teammates complete normally and the Lead calls TeamDelete, the on-disk state under ~/.claude/teams/ is fully cleaned up.
3. The Lead's statusline continues to show role chips for completed teammates — often duplicated, e.g. @raider @raider @sentinel @sentinel @vanguard @vanguard.
4. Chips persist for the remainder of the Lead session even after the teammate processes and tmux panes are fully gone.

This points at either a listener/handle leak per-spawn, or a conversation-buffer reference to completed sub-agent contexts that never gets released — either of which would line up with the 700MB+ growth in #8722.

What we've tried on our side

• Routing 20min+ implementation steps to non-teammate Agent({ isolation: "worktree" }) instead of teammate panes. Avoids the crash but we lose realtime pane visibility, which is our main reason for using teammates.
• Aggressive TeamDelete / tmux kill-pane cleanup at every phase boundary. Reduces orphan processes but does not clear the ghost statusline chips.

What would help most

• Any release note / known-issue pointer confirming whether the --resume loop and the parallel-agent crash are the same root cause or distinct
• A diagnostic flag (heap / handle dump per turn) we could run against a reproducing session and share anonymized output from
• Confirmation of whether statusline chip state is intended to be eventually-consistent with ~/.claude/teams/, or driven by a separate in-memory handle table

Happy to share anonymized --debug logs from a reproducing session. Please let me know the preferred format.

References

• Previous reports (closed / not-planned / locked): #8978, #8722, #8829
• Downstream context on our side (for reproducibility): vary3/agent-legion-cli — skills/al-teams/SKILL.md describes the orchestration pattern that triggers the symptoms.