Claude Code's built-in SendMessage tool collides with the AgentConnect messaging tool and silently swallows parent reports

[Poytr1]

Symptom

When a child session runs on the Claude Code runtime (claude-agent-acp), its tool list contains two messaging tools: AgentConnect's mcp__agentconnect__sendMessage (or an evaluation façade) and Claude Code's own built-in SendMessage tool (its agent-teams / subagent messaging feature, kind: "other", _meta.claudeCode.toolName: "SendMessage").

When the child is instructed to report a result back (the needsReply report-back directive), the built-in tool is a literal name match for the instruction — and the model picks it. The call "succeeds" inside Claude Code's own system, but the message never reaches the AgentConnect daemon: the parent session waits forever, and from the parent's view the child "completed its turn but returned no message".

Evidence (tool-surface A/B, 2026-08-09, 6 parent-session trials)

• 3 of 6 first attempts across both arms went to the built-in SendMessage instead of the AgentConnect tool; 2 of 6 trials lost the answer entirely this way (one per arm).

• The failing arm-B trial's artifacts contain zero occurrences of the string sendMessage in any text delivered to the child — the model was never taught that name in-session. The recorded call is unambiguous:

  {"title": "SendMessage", "kind": "other",
   "_meta": {"claudeCode": {"toolName": "SendMessage"}}}

  So this is not prompt leakage and not a tool-schema comprehension failure; it is a name collision inside the session's tool list. Both surface designs (production sendMessage and the primitives post façade) failed identically, which localizes the cause upstream of either.

• Method and full numbers: docs/designs/messaging-primitives-ab.md (PR test(evals): tool-surface A/B — shipped sendMessage vs messaging-primitives post #791). Related earlier finding (same delivery hazard, prose variant): the delegate-and-forward case in evals/test/delegate-and-forward-real.test.ts, where a headless child answered in ordinary prose and the answer was silently dropped.

Impact

Any production agent whose runtime is Claude Code can mis-route a parent report into the runtime's own messaging system. The failure is silent: no error, no delivery, no wake — the worst failure mode for delegation flows.

Proposed fixes (complementary, ordered by how directly they remove the cause)

1. Suppress the runtime's built-in messaging tools for AgentConnect-managed sessions. For sessions the daemon owns, Claude Code's SendMessage (and any sibling agent-teams messaging tools) is always the wrong answer and should not be offered. Investigate whether claude-agent-acp supports tool filtering (e.g. a disallowed-tools setting) and pass it from the runtime config; if it does not, file the capability request upstream.
2. Reply-hint the report-back directive (pi-intercom pattern): embed the exact, pre-filled call — mcp__agentconnect__sendMessage({"sessionId": "<filled>", "message": "..."}) — in the directive text instead of describing the tool by name, so the correct target is copy-paste unambiguous.
3. Inferred reply as a safety net (pi-intercom pattern): when a child session carries exactly one pending report-back obligation and its turn ends without having called the report tool, deliver its final ordinary output to the parent session (explicitly marked as inferred). This also fixes the prose-answer variant of the same hazard.

Fixes 2 and 3 make the system immune to the collision; fix 1 removes the collision itself.

[Poytr1]

Fixed by #801 (merged as 29feb9b) — the prompt-side precedence rule proposed here, measured before merging with the tool-surface A/B harness (PR #791), parent-session scenario, success criteria fixed before looking at results:

Metric	Before (6 trials)	After (10 trials, 5 per surface arm)
Trials with any built-in SendMessage attempt	3/6	0/10 (verified in scored attempts and raw ACP events)
Answers lost to the built-in	2/6	0/10
Total success (parent actually woken with the answer)	4/6	10/10
First-attempt correct form	0/6	4/10

The standing collaboration guidance now leads with: AgentConnect's MCP tools are the ONLY channel that reaches other agents and humans; similarly-named runtime built-ins (e.g. a bare SendMessage) do not reach AgentConnect and anything sent through them is lost. ~80 standing tokens per session; pinned by a contract test that also asserts the bullet leads the section.

Honest residue: the collision is eliminated in this sample and no answer was lost, but first-attempt behavior is 4/10, not 10/10 — the child still sometimes wraps the correct parent reply in extra (legal) postless calls. The three deeper fixes proposed here (suppress the built-in for daemon-owned sessions; reply-hint the exact pre-filled call; inferred reply as a safety net) remain worthwhile hardening if this ever resurfaces — n=10 screens for the large effect, it does not prove the collision extinct.

Run artifacts: ~/arena-runs/ab-2026-08-09/precedence-fix/ on the measurement host.

[Poytr1]

Reopening: the prompt-level mitigation from #801 has been reverted (see the revert PR) after a live in-thread regression, so the collision hazard this issue tracks is back.

What happened. In a real Slack thread, a turn-taking counting game ("take turns counting to 30") broke down on the Claude Agent runtime: instead of counting via ordinary thread replies, the agent routed every turn through sendMessage to "hand off" the next number to its peer, posting only meta-narration into the thread, with skipped and duplicated numbers in the visible count.

Mechanism. The #801 bullet said AgentConnect's MCP tools are the ONLY channel that reaches other agents and humans. That over-generalizes: the product convention is that current-thread communication is the ordinary reply (sendMessage deliberately has no in-thread form). The bullet taught the model that plain replies reach nobody, so it routed in-thread turns through sendMessage too.

Consequence of the revert. The parent-report collision hazard returns: with the bullet, parent-report delivery measured 10/10; without it, 4/6 (first attempts going to the runtime's built-in SendMessage, silently losing the report).

Next candidates:

1. A scoped rewrite of the bullet. Three-part precedence instead of "ONLY channel":

   • ordinary replies ARE the delivery inside the current thread/conversation;
   • AgentConnect's MCP tools are for reaching other conversations/sessions (peers privately, channel roots, parent sessions);
   • runtime built-in messaging tools (e.g. a bare SendMessage) reach nothing and must never be used.

   To be validated in the arena against BOTH the parent-session report-back scenario AND a new in-thread counting scenario before re-landing.

2. Mechanism-level fixes with no prompt blast radius (already listed on this issue): suppressing the runtime built-in tool via the ACP adapter, the reply-hint with a pre-filled call, and inferred reply.

Arena-backlog lesson. The A/B scenario matrix that validated #801 had no in-thread conversation scenario — which is exactly why this regression escaped. Adding an in-thread counting/turn-taking scenario to the matrix would have caught it, and should gate any prompt-side re-land.

[Poytr1]

The arena-backlog lesson above is now closed out: the A/B matrix has the in-thread gate scenario (PR #791, commits 36332e0 + db42907).

Scenario 5 — in-thread-count: one plaza thread, BOTH agents on the arm's surface, a human kickoff @-mentioning both ("take turns counting to 6, reply with just the next number" — names no tool/field, covered by the banned-vocabulary test). The agents continue via ordinary replies through the platform echo and the #549 continuation ladder. Daemon-judged (judgeThreadCount): hard pass = count reaches 6 via delivered thread replies, ZERO messaging-tool calls by either participant (product sendMessage/post, the other arm's tool, or the runtime built-in SendMessage — delivered or refused, any one is this incident's failure mode), no lost replies. Duplicates/skips/meta-narration/turns-per-number/tokens are reported soft metrics. Contract tests in the eval:collab:contracts gate replay the regression trace (sendMessage "handoff" ⇒ FAIL) and the clean reply-only trace (⇒ PASS), plus a scripted end-to-end fixture test proving the kickoff→echo→peer-continuation transport on a real daemon.

Baseline on the current (post-revert) prompt, 2026-08-11: 2 arms × 3 trials, real local Claude Code (sonnet), 6/6 clean passes — every trial exactly the bare numbers 1–6 in order, zero messaging-tool calls, zero duplicates/skips/meta-narration. Full table: docs/designs/messaging-primitives-ab.md §8.4.

Standing rule (collaboration-arena-baseline.md §4.2, messaging-primitives-ab.md §8.5): any change to the standing collaboration guidance or the parent-report append must now be validated against BOTH the parent-session scenario AND this in-thread scenario before landing — the two failure modes pull the guidance in opposite directions, so a candidate measured on only one is unvalidated. Runner: AGENTCONNECT_EVAL_AB_SCENARIOS=parent-session,in-thread-count npx vitest run evals/test/tool-surface-ab-real.test.ts.

Next candidates on this issue (the scoped precedence-bullet rewrite, adapter-level built-in suppression, reply-hint, inferred reply) can now be measured against both sides of the trade-off before any re-land.