{"version":"2.1.281","anchor":"remote-sessions-can-defer-connecting-mcp-servers-set-via-set","canonical_anchor":"remote-sessions-can-defer-connecting-mcp-servers-set-via-set","heading":"Remote sessions can connect MCP servers from mcp_set_servers after the turn starts","tier":"notice","area":"MCP","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/remote-sessions-can-defer-connecting-mcp-servers-set-via-set","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Remote sessions can connect MCP servers from `mcp_set_servers` after the turn starts\n\nIn remote sessions, MCP servers added with mcp_set_servers can connect in the background, with the next turn waiting up to 8 seconds\n\n**Unclear.** The finding does not say what triggers a `set_servers` call or how the relay decides which servers to mark.\n\n**What**\n\nMCP servers are external tools Claude Code connects to. A program driving Claude Code through the SDK can add them with an `mcp_set_servers` request. In remote sessions, those connects can now finish after Claude Code has replied, instead of holding up the reply.\n\n- Whether to defer is decided by a new check that replaces the old `mcpNonBlocking` value. The check returns \"off\" unless `CLAUDE_CODE_REMOTE` is set. It returns \"on\" only when the server flag `tengu_ccr_mcp_set_servers_defer_connect` is true, or `tengu_ccr_mcp_set_servers_defer_connect_relay` for relay-marked sessions. Both flags fall back to false, and nothing has been read about either for this release. Otherwise the check returns \"cold\" or \"off\", and only \"on\" defers.\n\n- A new `deferredMcpServersJoin` step runs before the next turn and waits for deferred servers that are still connecting. It waits only in relay-marked sessions, for at most 8000 ms after the deferred start, and not when the main thread was requested. The older `sdkMcpServersJoin` step still exists.\n\n- The startup wait for MCP servers in headless (non-interactive) mode gains `onlyServerNames` and `alsoWaitFor` options. There is a 500 ms cap for servers waited on only by name. Before, it could only wait on local servers and on remote servers named with `waitRemoteServerNames`.\n\n- Each apply of `mcp_set_servers` records whether it was deferred, the check's result and whether the session was relay-marked.\n\n**Why**\n\nIn cloud or remote sessions, adding MCP servers late no longer has to block the reply, and the first turn waits only a bounded time for them. Because the behaviour depends on server flags with a false fallback, it may not be active for you.\n\n- Area: MCP\n- Names: `set_servers`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}