Stdio server never exits after stdin EOF once a client has sent subscriptions/listen (2026-07-28)

Finding: In an external report against modelcontextprotocol/csharp-sdk (https://github.com/modelcontextprotocol/csharp-sdk/issues/1914), a stdio server built with ModelContextProtocol 2.2.0 reportedly does not exit after stdin reaches EOF if the client has opened a subscriptions/listen request under protocol 2026-07-28. The reporter says the process remains alive indefinitely, and that Claude Code 2.1.295 opens subscriptions/listen on every connection, leaving leaked server processes (51 counted on one machine in a day; unverified). Reported conditions: Windows, no WSL; a minimal server using StdioServerTransport and McpServer.Create with RunAsync called without a token. The reporter's table says clients that send initialize/initialized/tools/list (2025-06-18) or server/discover/tools/list (2026-07-28) and then close stdin lead to exit code 0, while server/discover, subscriptions/listen, tools/list leaves the process still running 15 s after EOF. Reporter's reading of the cause (not maintainer-confirmed, hypothesis): on EOF, StreamServerTransport.ReadMessagesAsync calls SetDisconnected, completing the message channel. McpSessionHandler.ProcessMessagesCoreAsync then leaves its read loop and, in its finally block, waits for all handlers to complete without first cancelling in-flight handlers. Handler tokens are linked only to a token cancelled by RunAsync(ct) or DisposeAsync. The stateful subscriptions/listen handler completes only on cancellation, so the wait never ends and RunAsync never reaches its DisposeAsync. The reporter says a long-running in-flight tools/call at EOF could hold the process similarly. Suggested fix direction from the reporter: cancel in-flight handler tokens once the transport completes, or have RunAsync return when the transport disconnects and let DisposeAsync cancel the remainder. Reported workaround (source-backed, not verified by KFA): pass a token to RunAsync and cancel it shortly after transport.MessageReader.Completion completes, allowing about 1 s drain for in-flight replies and then enforcing a bounded deadline. Limitations: this is a single external report with no KFA reproduction, no maintainer response in the supplied context (comment coverage may be partial), and no linked fix commit or release. The issue was OPEN at the time of the input.