Bug: Claude Haiku children finish successfully but do not reply to the parent Environment - Traycer host: 1.1.7, Windows x64 - Bundled Claude Code: 2.1.214 - Model:

claude-haiku-4-5-20251001

- Haiku runs with thinking disabled - Traycer A2A MCP server is authenticated and configured with

alwaysLoad: true

Impact Haiku currently cannot be used reliably as a Traycer child. It generates the requested answer, but the parent never receives it automatically. Reproduced in 3/3 fresh sessions. Actual behavior 1. Parent sends a message with

expectReply: true

. 2. The child receives an explicit instruction to call

traycer_send_message

with the supplied

responseId

. 3. Haiku generates correct terminal text, then returns

end_turn

without making a tool call. 4. Traycer leaves the response thread open and emits “finished its turn without replying.” 5. The answer is only recoverable by manually reading the child transcript. Expected behavior The generated answer should reach the parent and complete the response thread exactly once. Control A Sonnet High child using the same workspace, provider profile and A2A transport correctly called

mcp__traycer_a2a__traycer_send_message

and delivered its answer. Reproduction IDs - Haiku: agent

3106a155-6cac-4db6-b189-1b70e27a9118

- Response:

bb6258f2-47e5-4528-8fd8-d8d967f40fcc

- Provider session:

269c543e-0af3-43e4-b175-20f09e38d2bd

- Haiku: agent

91cc07eb-1bbb-4132-b027-7154a3aaaa0f

- Response:

92b406df-2480-4698-a8a7-aace88028e04

- Provider session:

528fc1f7-49d7-4a27-bcfc-7a9f294e42d6

- Haiku: agent

83094862-3f73-492f-9395-ed3a453aa6e9

- Response:

e0cad8ab-a4f7-40db-a016-a1906d257314

- Provider session:

8d3db9d5-e378-489b-8b54-9eb3cf1341bd

- Successful Sonnet control: agent

9ce62cb8-121a-4f69-85d1-51094181f603

- Response:

3028b59b-5e7e-432c-a833-6c3edbf947bd

- Provider session:

8c34f841-dd40-4841-a202-5de21afda470

Suggested fix At successful child-turn finalization, if an

expectReply: true

thread is still open: 1. Atomically check whether

traycer_send_message

already completed it. 2. If not, and non-empty terminal assistant text exists, deliver that text as the reply. 3. Record the delivery mode as

terminal-text-fallback

. 4. Ensure a concurrent or late tool reply cannot create a duplicate. 5. Retain the current inactivity/error behavior for empty, failed, stopped or cancelled turns. Acceptance criteria - Plain terminal child text completes the response thread once. - Normal reply-tool calls remain authoritative and create no fallback duplicate. - Tool-call/finalization races always produce exactly one reply. - A tool reply followed by a terminal acknowledgement does not send twice. - Empty/error/stopped/cancelled turns do not fabricate replies. - Joined messages sharing one response thread still complete atomically. - Three fresh Haiku children deliver 3/3 replies without transcript recovery. - Sonnet and another existing child route continue working without duplicates. I can provide the host-log excerpts and Claude session JSONL files if needed.