[BUG] opus-4-8 tool-call parse corruption inside in-process teammate: completed result undeliverable (SendMessage never parses), context poisoning on resume, TeamDelete permanently blocked

Environment

• Claude Code 2.1.172 (CLI, macOS / darwin 25.5)
• Model: claude-opus-4-8 (teammates spawned with model: "opus")
• Agent Teams: in-process teammates, subagent_type: "general-purpose"

Summary

The known model-side tool-call serialization bug (#64774, #63879, #64235 — stray token before <invoke> + missing namespace prefix, ~1.5% of tool calls on opus-4-8) has a compound, unrecoverable failure mode when it strikes an in-process teammate. In a normal session the bug is a transient nuisance (identical retry usually succeeds). Inside a teammate it cascades:

1. Completed work becomes permanently undeliverable. The teammate's review task and text generation completed normally — only tool-call serialization was corrupted. But a teammate's result delivery depends on a trailing SendMessage(to: "team-lead", ...) tool call succeeding, and every subsequent tool call serialized corrupted, so the finished result never reached the lead.
2. Context poisoning makes recovery impossible. Once the first corrupted call entered the transcript, nudging the teammate (2 attempts) produced resumed turns that imitated the agent's own corrupted plain-text format. Retries happen inside the poisoned context, so the per-call ~1.5% failure rate effectively becomes ~100% for that agent.
3. Team cleanup is permanently blocked. The poisoned teammate also cannot emit a parseable shutdown_response (another tool call), so TeamDelete fails forever with Cannot cleanup team with 1 active member(s). Related: #25371 (closed), #49671 / #53701 (closed NOT_PLANNED) — but unlike those, this member is alive and actively responding; it just cannot produce any parseable tool call.

Observed run (2026-06-11)

• 3 teammates spawned with identical configuration for a document review; 1 of 3 corrupted (probabilistic). The other 2 completed normally, including their SendMessage calls.
• Corrupted teammate transcript: 2-3 could not be parsed failures per turn across 3 turns; tool calls emitted as plain text inside text blocks; zero successful tool calls after onset.
• Suspected aggravator: long Japanese (CJK) payloads in tool-call arguments — consistent with the aggravators reported in #64774.

Corruption signature (sanitized excerpt from teammate transcript)

...normal Japanese review prose ends...

count
<invoke name="Bash">
<parameter name="command">cd /path/to/project; grep -n "..." FILE | head; ...</parameter>
<parameter name="description">Check ... consistency</parameter>
</invoke>
count
<invoke name="Bash">
...byte-identical retry, also emitted as plain text...
</invoke>
The model's tool call could not be parsed (retry also failed).

Note the stray count token before each <invoke> and the missing namespace prefix — the same signature documented in #63879. Full transcripts retained locally; sanitized excerpts available on request.

Why this is filed separately from the parse-bug issues

The serialization bug itself is model-side and already tracked. This report is about the harness-level amplification specific to Agent Teams:

• A plain Agent-tool subagent is structurally immune to the same corruption: its final text is the return value, so a completed task survives even if every tool call fails.
• A teammate's result delivery requires one more successful tool call at the end of its turn — a single point of failure with no fallback, no recovery path (nudge → poisoned imitation; shutdown → unparseable; TeamDelete → blocked until session end).

Suggested harness-side mitigations

1. Deliver a teammate's final assistant text to the lead automatically when its turn ends without a successful SendMessage (parity with Agent-tool return values).
2. On N consecutive parse failures, drop/resync the corrupted tail of the agent's context instead of retrying inside the poisoned transcript.
3. A force/discard option for TeamDelete when a member cannot produce parseable tool calls (re-raising #53701 with this concrete failure mode).