MCP_TIMEOUT env var is ineffective — inner @modelcontextprotocol/sdk requestTimeout (60s) overrides it

Summary

MCP_TIMEOUT env var does not actually control the MCP server connection timeout. The MCP Client from @modelcontextprotocol/sdk is instantiated without passing requestTimeout, so it defaults to 60 seconds. This inner timeout fires before the outer MCP_TIMEOUT wrapper, making the env var completely ineffective.

Reproduction

1. Configure an MCP server that takes >60s to respond to initialize (e.g., korotovsky/slack-mcp-server on a large Slack workspace — it caches users and channels before responding)
2. Set MCP_TIMEOUT=300000 (5 min) or even MCP_TIMEOUT=1800000 (30 min)
3. Run Claude Code with --mcp-config pointing to that server
4. Observe: the server is marked as failed after ~60s regardless of MCP_TIMEOUT

Root Cause

In the CLI source (cli.js v2.1.91), the MCP Client is created as:

new Client({
  name: "claude-code",
  version: "...",
  ...
}, { capabilities: {} });  // ← no requestTimeout

The @modelcontextprotocol/sdk Client defaults requestTimeout to 60000ms. The outer timeout wrapper using MCP_TIMEOUT is correct but never fires because the inner SDK timeout rejects the connect() promise first.

Expected Behavior

MCP_TIMEOUT should be passed as requestTimeout to the MCP Client constructor:

new Client({...}, {
  capabilities: {},
  timeout: parseInt(process.env.MCP_TIMEOUT || "", 10) || 30000
});

Environment

• Claude Code version: 2.1.91
• @anthropic-ai/claude-agent-sdk: ^0.2.77
• Running via gor-st/claude-code-action in GitHub Actions
• MCP server: korotovsky/slack-mcp-server v1.2.3 (stdio transport)
• Slack workspace: ~12.8k users, ~43k channels (caching takes 3-5 min)