stdio client never closes the server's stdin, so every client dispose burns the full ShutdownTimeout (5s by default)

[FrancescoCrecchi]

Summary

StdioClientSessionTransport.CleanupAsync waits up to ShutdownTimeout for the server process to exit on its own, and only then kills the process tree. But nothing ever asks the server to exit: the client never closes the child's standard input, which the specification defines as the graceful-shutdown signal. So for any server that is alive and well behaved, that wait always runs to the full timeout — 5 seconds by default — and the process is force-killed afterwards regardless.

Hosts that create and dispose a client per tool call pay this on every single call.

Version checked: v1.4.0 (same code on main at the time of writing).

What the spec requires

From basic/transports/stdio — Shutdown:

1. Closing the input stream to the child process (the server).
2. Waiting for the server to exit.
3. If the server does not exit within a reasonable time, forcibly terminating the process…

and:

Servers should exit promptly when their standard input is closed or reads return end-of-file […] the primary graceful-shutdown signal and the only portable one.

Step 1 is missing in the client.

What the SDK does

CleanupAsync order of operations:

1. WaitForProcessExitAsync() — bounded by _options.ShutdownTimeout
2. detach the stderr handler
3. StdioClientTransport.DisposeProcess(..., _options.ShutdownTimeout)

WaitForProcessExitAsync on .NET:

using var timeoutCts = new CancellationTokenSource(_options.ShutdownTimeout);
await _process.WaitForExitAsync(timeoutCts.Token).ConfigureAwait(false);

DisposeProcess:

processRunning = processRunning && !HasExited(process);
if (processRunning)
{
    process.KillTree(shutdownTimeout);
}

There is no StandardInput.Close() / .Dispose() anywhere in StdioClientTransport.cs or StdioClientSessionTransport.cs. The default:

/// The amount of time to wait for the server to shut down gracefully. The default is 5 seconds.
public TimeSpan ShutdownTimeout { get; set; } = TimeSpan.FromSeconds(5);

The doc comment says "wait for the server to shut down gracefully" — but the server was never told to, so the wait is guaranteed to expire.

The server side already handles it

StreamServerTransport's read loop, same version:

if (line is null)
{
    LogTransportEndOfStream(Name);
    break;
}

EOF breaks the loop, SetDisconnected completes the transport, the process exits. So closing stdin would make servers built on this SDK exit in milliseconds — the fix needs no change on the server side.

Impact

Measured on a host that creates and disposes a stdio client per tool call: 6.7–7.0s wall clock per tool call, of which ~5s is this wait. One of the measured calls was a query that returned an empty array — no data, no work — and still took 6.95s. Eighteen tool cycles across four configurations, all in the same band.

Two consequences, not one:

1. Latency: a fixed ~5s added to every client dispose.
2. The server is always force-killed. Because the wait can only expire, KillTree always runs, so the server never executes its own shutdown path — no flush, no cleanup, no chance to release resources. Lowering ShutdownTimeout as a workaround makes the kill arrive sooner, so it trades latency for a harder kill rather than fixing it.

Suggested fix

Close the child's standard input at the start of CleanupAsync, before WaitForProcessExitAsync. The subsequent wait then ends when the server actually exits, usually in milliseconds, and KillTree degrades to the safety net the spec intends. Optionally escalate SIGTERM before SIGKILL on POSIX, as the spec describes.

Repro

Start any stdio server built on this SDK, issue one tool call, dispose the client, and time the dispose. It returns after ShutdownTimeout, independently of what the server does. Setting ShutdownTimeout to a small value makes the dispose proportionally faster, which confirms the wait is the whole cost.