What
MCP 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.
- Whether to defer is decided by a new check that replaces the old
mcpNonBlockingvalue. The check returns "off" unlessCLAUDE_CODE_REMOTEis set. It returns "on" only when the server flagtengu_ccr_mcp_set_servers_defer_connectis true, ortengu_ccr_mcp_set_servers_defer_connect_relayfor 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. - A new
deferredMcpServersJoinstep 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 oldersdkMcpServersJoinstep still exists. - The startup wait for MCP servers in headless (non-interactive) mode gains
onlyServerNamesandalsoWaitForoptions. 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 withwaitRemoteServerNames. - Each apply of
mcp_set_serversrecords whether it was deferred, the check's result and whether the session was relay-marked.
Why
In 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.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
The finding does not say which MCP servers count as deferred or when a turn actually waits for them.