HTTP transport hardcodes 60s fetch timeout, ignores MCP_TOOL_TIMEOUT

Bug Description

The HTTP MCP transport has a hardcoded 60-second AbortSignal.timeout() on fetch requests that is independent of and ignores the MCP_TOOL_TIMEOUT environment variable. MCP tool calls that take longer than 60 seconds return empty {} responses silently — no error, no timeout message.

Environment

• Claude Code version: 2.1.79
• MCP transport type: HTTP (Streamable HTTP)
• OS: Ubuntu (EC2)

Steps to Reproduce

1. Set MCP_TOOL_TIMEOUT=300000 (5 minutes) as an environment variable
2. Configure an HTTP MCP server in .mcp.json
3. Call an MCP tool whose server-side execution takes >60 seconds
4. The tool returns empty {} at exactly 60 seconds, even though the server completes successfully at ~90 seconds

Root Cause

In the minified CLI source (cli.js), the HTTP transport creates a hardcoded abort signal:

bf4 = 60000
// ...
let _ = AbortSignal.timeout(bf4);

This AbortSignal.timeout(60000) is applied to every HTTP fetch call to the MCP server. It is not configurable and does not read from MCP_TOOL_TIMEOUT or any other environment variable.

Meanwhile, MCP_TOOL_TIMEOUT correctly sets the protocol-level timeout (oe9, defaulting to 1e8 / ~27 hours), but this never fires because the HTTP fetch is already aborted at 60 seconds.

Evidence

Session log from a tool call that took ~90s on the server side:

13:55:08.181 — Claude calls mcp__snaplogic-core__LoopioGetAllProjects
13:56:08.346 — Response: "(mcp__snaplogic-core__LoopioGetAllProjects completed with no output)"

Exactly 60.165 seconds. Server-side pipeline logs confirm execution completed successfully at ~90 seconds with actual data.

Expected Behavior

The HTTP transport fetch timeout should respect MCP_TOOL_TIMEOUT (or at minimum MCP_TIMEOUT), allowing tool calls to complete within the configured timeout window.

Workaround

None currently viable:

• MCP_TIMEOUT — only controls server startup timeout
• MCP_TOOL_TIMEOUT — controls protocol timeout but HTTP fetch aborts first
• Patching the minified binary is fragile and lost on updates

Suggested Fix

The HTTP transport should use MCP_TOOL_TIMEOUT (or a dedicated MCP_HTTP_TIMEOUT) for its AbortSignal.timeout() instead of the hardcoded 60000ms value.