Stdio transport does not expose process exit code on server launch failure

[hulumane]

When launching an MCP server via the Stdio transport, the SDK does not expose the process exit code if the server process terminates with a non-zero exit code. This makes it impossible for the client to distinguish between different failure modes based on the exit code.

Motivation
This is critical for scenarios like the Windows On-Device Registry (ODR), which returns specific exit codes to signal distinct error conditions (e.g., "Feature unavailable", permission errors, etc.). Without access to the exit code, the client cannot provide meaningful error messages or take appropriate recovery actions — all failures appear identical.

Expected Behavior
When the MCP server process exits with a non-zero exit code, the SDK should surface that exit code to the caller (e.g., via the exception, a result object, or an event), so the client can inspect it and react accordingly.

Current Behavior
The exit code is silently discarded. The client receives a generic failure indication with no way to determine the specific exit code returned by the server process.

Suggested Approach
Expose Process.ExitCode on the StdioClientTransport or include it in the exception thrown when the process terminates unexpectedly.
Consider adding an ExitCode property to a transport-level error/event type.
Environment
SDK: MCP C# SDK (latest)
OS: Windows

[stephentoub]

Does #1368 address the concern?

[hulumane]

Thanks Stephen! This looks great — the Completion property on McpClient with StdioClientCompletionDetails exposing ExitCode, ProcessId, and
StandardErrorTail is exactly what we needed. This addresses our concerns from #1332 around surfacing process exit codes for distinguishing
failure modes. Really appreciate the thorough approach with the extensible ClientCompletionDetails base class too.

Do you have a sense of which version/release this fix will land in?

[stephentoub]

Soon-ish 😄