[Feature] SessionHooks should support multiple handlers per hook slot

まず SessionHooks と既存のフック呼び出し動作、特に OnPostToolUse と OnPreToolUse を見つけます。現在の single-delegate と multicast-delegate の動作を、提案されている UsePreToolUse および UsePostToolUse パイプラインと比較します。ハンドラーを明示的な順序で組み合わせ、フックの実行を検査、変更、短絡、または転送でき、暗黙的に上書きされないようになれば完了です。

At least in C#, SessionHooks properties (OnPostToolUse, OnPreToolUse, etc.) are single-assignment delegates. This makes it easy to accidentally clobber a previously-registered handler with =, and there is no SDK-level way to compose multiple handlers.

Why this matters for library authors

We are building a library on top of the SDK. Our framework needs to register its own hooks (for example, observing update_todo calls in a post-tool-use hook to persist state). But we also need to leave hook slots open for our downstream consumers to register their own hooks.

Today there is no safe way to do this. We can build our own closure-chaining helper (capture the existing delegate and wrap it), but since SessionHooks properties are public settable, any downstream consumer doing config.Hooks.OnPostToolUse = myHandler silently clobbers our framework hook. We cannot prevent that as a library because we do not control the downstream code.

Multicast delegates (+=) do not appear to work either, because await hooks.OnPostToolUse(...) only awaits the last delegate in the invocation list.

What would help

A middleware-style pipeline where each handler receives a next delegate and decides whether to call it, short-circuit, or modify the input/output. This gives callers full control over composition without the SDK needing different resolution rules for different hook types:

hooks.UsePreToolUse(async (input, invocation, next) => {
    // inspect, modify input, or short-circuit
    return await next(input, invocation);
});

hooks.UsePostToolUse(async (input, invocation, next) => {
    var result = await next(input, invocation);
    // observe, modify result, or replace it
    return result;
});

This is the same pattern as ASP.NET Core middleware and Akka message pipelines. It is simple to reason about, order is explicit, and each handler can decide independently whether to pass through or stop the chain. No special-case semantics per hook type needed.

Workaround

We worked around this by moving our observer to session.On() events instead of hooks, which works for our case but is not a general solution for hooks that need to mutate tool behavior.