[BUG] HTTP MCP client does not re-attach standalone GET SSE notification reader after an in-process re-initialize — server→client notifications silently stop (survives manual /mcp reconnect)

Summary

For an HTTP (Streamable HTTP / SSE) MCP server that sends server-initiated notifications over the standalone GET /mcp SSE stream, the Claude Code MCP client stops rendering those notifications after an in-process transport re-initialize (e.g. the MCP server restarts and the already-running client auto-re-initializes on its now-stale session). The request/response (POST) path keeps working — the client can still call tools — but server→client notifications are silently dropped client-side. Only a freshly-spawned client process or a manual /mcp reconnect re-attaches the notification reader.

No error is surfaced; from the user's side the agent simply never receives pushed notifications after a server restart.

Environment

• Claude Code CLI 2.1.196
• MCP protocol 2025-11-25, HTTP Streamable transport with a standalone GET /mcp SSE stream for server-initiated messages
• Server sends notifications/* over the standalone GET SSE stream

Repro (byte-identical wire A/B)

1. Stand up an MCP HTTP server that pushes a server-initiated notification to a connected client over the standalone GET /mcp SSE stream.
2. Client A (fresh process): start a new Claude Code session, connect, then have the server push a notification → notification renders. ✅
3. Client B (in-process re-init): take an already-running Claude Code session and force an in-process MCP re-initialize — e.g. restart the MCP server so the client auto-re-initializes on the stale session (or otherwise re-init the transport without spawning a new process). Then have the server push the same notification → notification does NOT render. ❌
4. Capture the wire on both: the handshakes are byte-identical — same initialize params, same POST initialize → POST notifications/initialized (202) → GET /mcp → SSE open, same standalone_sse=true single _GET_stream, same SSE write of the notification frame. The server does the same thing for both; the divergence is entirely client-internal at render time.
5. On Client B, run /mcp to reconnect → the notification reader is re-attached and subsequent pushes render again. ✅ (A full client restart also fixes it, but loses session context.)

Expected

After an in-process MCP re-initialize, the client should re-attach (re-subscribe to) the standalone GET SSE notification stream so server-initiated notifications continue to be processed/rendered.

Actual

The notification-stream reader is not re-attached on an in-process re-initialize. Server pushes are accepted at the transport layer (server logs the SSE write) but never surface in the client. Recovery requires a fresh process or a manual /mcp reconnect.

Impact

Any MCP server that relies on server-initiated notifications loses that channel to every already-running client after a server restart — silently, with no surfaced error. Send-path (tool calls) masks the problem because it keeps working.

Related

• #70386 is a different HTTP-MCP session-handling bug (drops Mcp-Session-Id on tools/list, a request-path failure). This report is the receive/notification-reader path: requests succeed, only server→client notifications stop.