MCP startup wait on relay workers can follow a new relay-hold check

What

Before running its first command, Claude Code can wait for MCP servers (external tools it connects to) to finish starting. A worker is a Claude Code process running remotely or behind a bridge. Previously, whether it was relay-marked decided that wait on its own. There is now a separate relayHold value, controlled by a new flag passed as relayHoldFollowsBootVerdict.

• The flag is read at startup from the gate tengu_dapper_platypus. A gate is a switch Anthropic can turn on or off remotely. Nothing has been read about this gate's state, so whether it is on is unknown.
• With the flag set, the relay hold applies only when a new check, relayStillUsableInProcess, says the relay can still be used in this process. With the flag off, the old behaviour applies.
• When a relay-marked worker gets no relay hold, it logs: "relay-marked worker: no relay hold (its relay can no longer be used in this process); the first command waits for MCP servers as on an unmarked worker".
• A new launchNamed setting, a mcpConnectKickedAtMs value and a check at the start of the transcript are wired into the wait handling.
• CLAUDE_CODE_MCP_STARTUP_WAIT_MS is now capped by the same limit as the connector prewait, the short wait for connectors before the first command, instead of its own separate limit.

Why

This changes how long headless or relay workers wait for MCP servers before their first command. A worker whose relay is no longer usable waits like an ordinary worker instead of relying on a relay it cannot use. If you set CLAUDE_CODE_MCP_STARTUP_WAIT_MS, the upper limit on your value may now differ.