Support repeat initialize on a persistent stdio connection used by cloud bridges

Request

Could the SDK offer a supported way to tolerate repeated initialize requests on one persistent stdio server connection, such as returning the established initialization result for compatible repeats? This is an integration feature request; it does not claim that the MCP specification requires accepting repeated initialization.

Environment

• Stock iMCP 1.8.0, build 25, using Swift MCP SDK 0.12.0.
• ChatGPT cloud custom connector through tunnel-client 0.0.16+5f99daabd4aa4a77049e6d81d54a0d8c18335397, forwarding to one persistent bundled imcp-server child over stdio.
• An external initialize-only adapter removes capabilities.experimental["openai/visibility"] to bypass the separate capability-decoding defect in #262 / PR #276. iMCP itself is unmodified.

Observed behavior

Attended ChatGPT connector setup reached iMCP's approval dialog, and the user approved with persistent trust. ChatGPT still showed a generic setup error. Transport metadata recorded four initialize exchanges on the same unchanged child process, no tools/list, and a downstream JSON-RPC error on the latest initialize. No transport timeouts were recorded.

The retained metadata does not establish whether the first initialize succeeded, whether all initialize parameters were identical, or the later error's integer code or message. “Server is already initialized” and -32600 were not observed in the retained responses. No synthetic reproduction of that later error was run.

Source-supported concern

The 0.12.0 initialization handler checks isInitialized before invoking the initialization hook and throws MCPError.invalidRequest("Server is already initialized") on repeats. invalidRequest maps to -32600.

This source behavior is consistent with the observed sequence, but the retained evidence does not confirm it caused the later failure. A cloud bridge can forward multiple initialization exchanges to one long-lived stdio child, exposing a lifecycle mismatch with the SDK's one-initialize state.

Proposed direction

Provide a supported mode for compatible repeat initialization, preserving response IDs and the established approval state, with defined handling for repeated notifications/initialized. Alternatively, document the supported bridge lifecycle that gives each initialization exchange the server state it needs.

Regression coverage for an idempotent mode should initialize successfully, send a compatible second initialize with a different request ID on the same connection, verify the returned result and ID without repeating the approval hook, then verify that tool discovery still works.

Found: 2026-10-30. Impact: cloud connector setup remains blocked; repeat-initialize causality is unconfirmed.