fix(claude-sdk): keep SDK loop alive when end_turn / react fails so the model can retry

[claudiusthebot]

Summary

The PostToolBatch hook used to terminate the SDK query loop the moment it saw a turn-terminator tool call in the batch — with zero check on whether the call actually succeeded. When the terminator's delivery failed (e.g. Telegram rejected end_turn for "Message too long", invalid chat_id, network blip), the loop exited as if delivery had worked. The model saw the error in its tool result but had no model turn left to react.

End result: the user saw nothing and the turn was silently dropped.

Canonical incident

2026-05-13 13:11Z (Pandario reply 226264). I tried to deliver an end-of-turn of 4326 chars. Telegram's cap is 4096. Bridge returned {ok: false, error: \"Message too long (4326 chars, max 4096).\"}. Hook fired regardless. Turn ended. User pinged the bot 24 min later asking what happened.

Fix

• New helper isFailedToolResponse(response: unknown): boolean that parses the bridge response in any of its three observed shapes (raw {ok: false} object, JSON string, MCP content envelope [{type:\"text\", text:\"<JSON>\"}]) and returns true iff failure is affirmatively detected.

• turnTerminatorHook now consults the terminator's tool_response. If failure is detected, returns { continue: true } and logs that the loop is being preserved — model receives the error in the next assistant turn and can retry / message the user about the problem.

• Conservative default preserved: any unrecognizable / missing / parse-failed response keeps the current terminate-on-success perf path. Same happy-path latency, no regression for tools that don't return ok-shaped JSON.

Test plan

• 7 new PostToolBatch turn-terminator hook > preserves SDK loop on failed terminator cases:
  • end_turn fail as raw {ok:false} object → loop alive
  • end_turn fail as JSON string → loop alive
  • end_turn fail wrapped in MCP [{type, text}] envelope → loop alive
  • react (strict terminator) fail → loop alive
  • non-terminator send fail → pass-through unchanged (hook never fires for it)
  • end_turn success → still terminates (no regression)
  • end_turn with missing / garbage response → still terminates (conservative default)
• 12 new unit tests for isFailedToolResponse covering every input shape:
  • Raw object {ok:false} / {ok:true}
  • JSON string \"{...}\" for both
  • MCP envelope for both
  • null / undefined / \"\"
  • Strings without \"ok\" (cheap skip)
  • Unparseable strings containing \"ok\"
  • Objects without ok field
  • Nested arrays of content blocks
• npm run typecheck clean
• npm run lint — no new warnings
• npm test — 2002/2015 pass, 1 pre-existing flake in package.functional.test.ts unrelated (same flake on main when tests run on a host where Talon daemon is already live — status returns "running" instead of "stopped").

🤖 Generated with Claude Code

[claudiusthebot]

Superseded by a cleaner approach — see follow-up PR. The content-sniffing hook in this PR is fragile (frontend coupling, schema drift, false positives). Replacing with: make end_turn / react (strict-terminator) tools throw new ToolDeliveryError(...) on bridge {ok:false}, then handle PostToolUseFailure via a per-session failed-id set that PostToolBatch consults. SDK's native error pipeline, no string matching, frontend-agnostic.