Session Close Notification for Stateful Connections (MCP Clients)

[lokendra-ss-18283]

Describe the bug

• Ref - https://github.com/modelcontextprotocol/typescript-sdk/blob/v1.x/src/client/streamableHttp.ts#L623

Current Issue:

When a client connects, a stateful session is established between the client and server to support features like elicitation, where the server needs to look up client metadata using session state for each incoming message. However, there is currently no mechanism to inform the server when a client disconnects. This results in stale sessions accumulating on the server side, causing unnecessary memory and resource bloat.

To Reproduce
Steps to reproduce the behavior:

1. Connect to any MCP Clients, On client disconnect the session close is not being handled properly since sessionTermination is made optional.

Expected behavior

Session Cleanup:

The MCP Client SDK should automatically handle session cleanup when a client disconnects. If a host needs to persist a session for reconnection purposes, it should be able to store the sessionId and reinitialize the session with the same ID at a later point.

This would allow MCP Servers to handle client exits gracefully and keep stale sessions from accumulating over time.

Possible Solution:

Upon investigating the SDK, I found that a terminateSession method is exposed but never invoked automatically — leaving session cleanup entirely up to the caller. This creates ambiguity: it's unclear whether and when callers are expected to call it, and in practice it often goes unused.

Additional context
In addition, it would be useful to include a metadata key during client initialization that indicates whether automatic session cleanup is enabled. This allows the server to decide whether it should persist session state or rely on client-driven cleanup behavior.

[lokendra-ss-18283]

In addition to this, I found a few other issues. These are observations I came across while working with the SDK, and they may or may not reflect intended behaviour. Happy to hear your thoughts and discuss further.

1. SessionID Should Be Controlled by the SDK, Not the Transport Layer

Problem

Currently, the sessionId is derived during transport initialization, which introduces a critical flaw in multi-host environments.

Consider a client that uses a simple counter as its sessionId. If the same client is shared across multiple AI hosts — such as Claude, VS Code Copilot, Cursor, etc. — every connection request from that client will arrive at the server with the same counter-based value as the sessionId. This means different hosts end up sharing or colliding on the same session, which is incorrect behaviour.

Root Cause

The sessionId should not be sourced from or influenced by the transport layer or the client implementation. Allowing this creates:

• Session collisions across multiple hosts using the same client
• Unpredictable session identity depending on client internals
• No guarantee of uniqueness across concurrent connections

Proposed Behavior

• The SDK should have full ownership and control over sessionId generation
• SessionId should be generated at connection time by the SDK itself (e.g., a UUID), ensuring uniqueness regardless of the client implementation
• SessionId should be immutable once assigned — it must not be overridable by the transport or the caller
• If a host needs to resume a session, it should do so through an explicit opt-in mechanism (e.g., passing a previously stored sessionId to a reconnect API), rather than having the client dictate the ID on every connection

Expected Outcome

Each connection to the server results in a guaranteed unique sessionId, managed entirely by the SDK. This eliminates session collisions in multi-host environments and makes session identity predictable and safe.

2. Client Transport Should Not Allow Connections Without a Client Object

Problem

It is currently possible to instantiate a client transport (e.g., StreamableHTTPClientTransport) and establish a connection directly, without an associated McpClient object. This is observable in proxy implementations like mcp-remote, where a StreamableHTTPClientTransport is created and used to communicate with the upstream server independently of any client.

Why This Is a Problem

While this may appear to work correctly today, it establishes a structurally incorrect pattern:

The connection should be owned and initiated by the client, not the transport.

The transport layer is responsible for how data is sent and received — not for owning the lifecycle of a session. When a transport connects without a client, there is no client context, no session ownership, and no guarantee that future client-level handling (e.g., session management, lifecycle hooks, capability negotiation) will be applied correctly.

If any mandatory client-side handling is introduced in the future — such as the session cleanup mechanism described in related issues — proxies and transports that bypass the client object will silently miss that handling, leading to subtle and hard-to-debug inconsistencies.

Proposed Behavior

• Client transports should require a client object to initiate a connection
• Attempting to call connect() on a transport without an associated client should result in a clear error or be prevented at the API level
• Proxy implementations like mcp-remote should create a proper McpClient instance and connect through it, rather than using the transport directly

Expected Outcome

The client object becomes the single, authoritative entry point for all connection lifecycle management. This ensures that any current or future client-level handling is consistently applied, regardless of the use case or deployment pattern.

[aicayzer]

Have a fix ready for this on aicayzer/typescript-sdk:fix/streamable-http-terminate-session — diff vs v1.x: v1.x...aicayzer:typescript-sdk:fix/streamable-http-terminate-session

Shape:

• close() awaits terminateSession() before aborting the controller (the DELETE is bound to the abort signal so the order matters)
• Best-effort: failures and 405 surface via onerror but don't block teardown
• No-op when there's no active session; idempotent
• 4 new tests + changeset; full suite (1583 tests) green; typecheck + lint clean

Was going to open as a PR but hitting aicayzer does not have the correct permissions to execute CreatePullRequest against this repo — other recent external PRs are landing fine so it looks specific to my account. If a maintainer could pull the branch directly or let me know what's up with the permissions, happy to follow up.