Client transports/sessions swallow the original exception; applications cannot classify 401/403/429 transport failures #3569

Initial Checks

• I confirm that I'm using the newest release of my line (verified on main and 2.2.0)
• I confirm that I searched for my issue in the issues before opening this one (searched "exception pending request", "error classification", "McpError generic")

Release line

v2 (v1 shares the code)

Description

When a transport request fails mid-flight (HTTP 401/403/429, connection reset, etc.), the client transports log the exception and close the stream, and pending send_request callers get a generic closed-stream error. The original exception — with its status code — never reaches the application, so a host cannot distinguish "token expired, re-authorize" from "rate limited, back off" from "server gone".

Proposal, in two parts (we run both in production and can PR them):

1. SSE/streamable-HTTP transports forward the caught exception into the read stream (instead of only logger.exception), so the session sees it.
2. Client/shared sessions deliver that raw exception to the pending request(s) — the default message handler re-raises Exception instances — so send_request callers receive the real httpx.HTTPStatusError and can classify it.

One caveat worth discussing: httpx exceptions stringify with the request URL, which can carry credentials in query strings; our transport-side change logs only the exception type name and leaves scrubbing to the application that receives the raw exception.

Happy to be assigned and open the PR(s).

🤖 Generated with Claude Code