SDK hook swaps no longer leave tool calls hanging; stuck ones now ask you to retry.
What's wrong with this entry?
When the process that owns the stdin stream re-initializes and sends hooks along with it, the previous hook callbacks are retired and the new set is registered through one shared helper, and the reply to the initialize request states whether those hooks were applied. Any tool call whose PreToolUse hook never received an answer is no longer left hanging or quietly allowed through: it is settled with an explicit message asking you to retry. This is on for everyone on the SDK path in this build, with no flag to enable.
- The synthetic result for an unanswered call reads: "The SDK host reconnected before its PreToolUse hook answered, so this tool call was not executed. No one denied it; retry the same tool call."
- Only a host that owns stdin locally can replace hooks this way. The transport flag permitting it defaults to true on the base transport and is overridden to false on the remote transport, so a client joining over the remote path cannot swap the hook set.
- The
tengu_reinit_pending_redeliverytelemetry event, which fires when a re-initialization redelivers pending work, gained three fields:host_hooks_resent,host_hooks_appliedandn_settled_hook_callbacks.
The SDK host reconnected before its PreToolUse hook answered, so this tool call was not executed. No one denied it; retry the same tool call., host_hooks_resent
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
SessionEnd hooks lose the
bypass_permissions_disabledreasonBoth mention hook
-
v2.1.236
Hooks and Ctrl-C go quiet once shutdown has started
Both mention hook
-
v2.1.236
Shutdown seals transcript writes and gives SessionEnd hooks more time
Both mention hook