[BUG] .mcp.json per-server `timeout` field no longer honored for HTTP MCP tool calls since 2.1.113 (native binary transition)

Summary

Since 2.1.113 (the release that moved the CLI to a native Claude Code binary), the project-level .mcp.json per-server timeout field appears to no longer be honored for HTTP MCP transport. Long-running tool calls that used to complete successfully in 2.1.107 now time out at ~60s, regardless of the timeout value configured.

This makes HTTP MCP servers that expose legitimately long-running tools (agentic workflows, batch briefings, long SSE streams) unusable from Claude Code.

Regression Evidence

Same .mcp.json (unmodified since 2026-04-13), same HTTP MCP server, same tool (dpc_execute briefing mode):

| Claude Code version | Result | Evidence |
|---|---|---|
| 2.1.107 (2026-04-14 session) | ✅ 36 long tool calls in one session, max elapsed 188s | Session JSONL log shows elapsed_seconds: 188, 181, 181, 180, 180, 172, 172, 167, 167, 167, 166, 166, 147, ... for mcp__<server>__dpc_execute with mode="briefing" |
| 2.1.114 (2026-04-18, today) | ❌ Consistent "The operation timed out" at ~60s | Multiple retries — all identical tool calls that previously succeeded now fail |

Environment:

• Install: ~/.local/bin/claude → ~/.local/share/claude/versions/2.1.114 (Mach-O 64-bit arm64, macOS 25.3.0)
• Transport: HTTP MCP server (internal)
• .mcp.json (project-level):

``json
"my-server": {
"type": "http",
"url": "http://...",
"headers": { "x-api-key": "..." },
"timeout": 3600000
}
``

• Tool call: single invocation, not concurrent

Hypothesis

The 2.1.113 CHANGELOG mentions two MCP-relevant changes:

- Changed the CLI to spawn a native Claude Code binary (via a per-platform optional dependency) instead of bundled JavaScript - Fixed MCP concurrent-call timeout handling where a message for one tool call could silently disarm another call's watchdog

The native binary transition likely dropped the code path that reads mcpServers[<name>].timeout from .mcp.json for HTTP transport, falling back to a hardcoded ~60s default. The concurrent-call timeout fix may also have unified timeout handling in a way that overrides the per-server override.

Reproduction

1. On Claude Code 2.1.113+, configure an HTTP MCP server in project-level .mcp.json with "timeout": 3600000 (1 hour).
2. Invoke an MCP tool whose backend takes >60s to stream the first complete response payload (e.g., an agentic workflow that collects SSE events before returning).
3. Expected: Tool call completes within the configured timeout budget (or server-side timeout, whichever is shorter).
4. Actual: "The operation timed out" at ~60s wall-clock, regardless of the timeout field.

Control (same machine, downgrade to 2.1.107 via ln -sf .../versions/2.1.107 ~/.local/bin/claude, restart session): same tool call completes in 100-188s successfully.

Impact

• HTTP MCP servers that front any long-running agent system (Claude Agent SDK, LangGraph, Celery-backed workers) are blocked from Claude Code tool invocation since 2.1.113.
• The only workarounds discovered in my project are (a) downgrade to ≤2.1.112, or (b) route all work through a separate HTTP script that bypasses Claude Code's MCP client entirely. Neither is acceptable for interactive sessions.
• Related prior issues: #22542 (configurable MCP tool timeout — previously marked "not planned") assumed 60s was always hardcoded. This report shows it was not always hardcoded — .mcp.json's timeout field worked in 2.1.107 and earlier. That field regressed in 2.1.113.

Ask

1. Confirm whether .mcp.json.mcpServers[].timeout is intended to be honored by the native binary for HTTP transport.
2. If yes → restore the code path that was dropped in 2.1.113.
3. If no → document the removal in the CHANGELOG and provide an alternative (environment variable, CLI flag, or per-call parameter). The silent behavior change is the main problem — users with working configs don't discover the regression until a tool times out in production.

Environment

• OS: macOS 15 (Darwin 25.3.0, arm64)
• Claude Code: 2.1.114
• Shell: zsh
• MCP transport: HTTP (streaming SSE)