[BUG] Claude code does not obey values of MCP_TIMEOUT longer than 60 seconds

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/7575
2. https://github.com/anthropics/claude-code/issues/424

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I think mine #17662 got marked as a duplicate.
I thought this was an Anthropic API server issues (and their support even told me that they limited the tool call time to 1 minute due to "incidents")
But purely by accident i ran it on v2.0.32 and there my long running mcp tools work perfectly

The original issue described here is about a local stdio MCP server (linux sleep infinity command, not an http MCP server).

@Peter4daggai - please don't upvote the "Found possible duplicate issues:" bot like in https://github.com/anthropics/claude-code/issues/16837#issuecomment-3723367123 or https://github.com/anthropics/claude-code/issues/17662#issuecomment-3737842796, because by upvoting you indicate the issue is a duplicate, and the bot should close it. You need to downvote the bot message to indicate you want to keep the issue open.

The standalone reproduction for the MCP_TIMEOUT environment setting, is present for me since 1.0.113 https://github.com/anthropics/claude-code/issues/7575.
You could try to perform the reproduction steps described in this issue, with the latest 2.1.7 release, as 2.0.32 is old.

@marcindulak I wont. And thanks for telling me that. I read it as "or comment" so i commented on my issue immediately.

I know 2.0.32 is old I was happily running my mcp tools on 2.1.4 (or 5 not sure) when last weekend it stopped working. I then reverted as far back as 2.1.1. Still did not work so I and Anthropic's support deemed it an API server issue and not Claude Code. The issue was deliberate the AI said because of some "incidents" so they took it down from 5 minutes to 1 minute. But then my colleague said he did not have the issue. I was amazed at the fact he ran it all successfully on his machine where he had 2.0.32. I reverted to that version and it also worked for me. Very strange indeed.

I also notice this issue is about the startup time of the server my issue is about MCP_TOOL_TIMEOUT i.e. the tool take about 2 minutes to return a result (transport=http)

Long starting mcps and long running mcps should be a user option
Please bring back MCP_TIMEOUT and MCP_TOOL_TIMEOUT

Also if there's a way to contribute to solving this please refer us to which codebase this belongs because i could not seem to find those implementations

People suggested in https://github.com/anthropics/claude-code/issues/424#issuecomment-2722227863 that the 60 seconds limit is due to Claude Code (and Gemini CLI) somehow using the default value from https://github.com/modelcontextprotocol/typescript-sdk/blob/b0ef89ffaf6db8b3c52cd8919e8949b0f1da9ca4/packages/core/src/shared/protocol.ts#L110

.

.

.

.

Additional data point from the field — a different angle on this same class of bug.

We run a self-hosted MCP server with a long-poll tool (wait_for_channel_event — a multi-agent message broker subscribe primitive). The expected wait window is up to 5 minutes, well within the documented MCP server-side ceiling but obviously above any client cap.

To work around exactly this class of timeout, we shipped a server-side keepalive (FastMCP ctx.report_progress() frames at 30s cadence — well inside the 60s default) on the assumption that any properly-implemented MCP client would reset its tool-call timer on progress notifications. Reference design: RequestOptions.resetTimeoutOnProgress: true from the TypeScript SDK.

It did not help. Empirically, our wait_for_channel_event calls from Claude Code via mcp-remote bridge time out at ~30 seconds with MCP error -32001 Request timed out, regardless of:

• Server-side keepalive frames being sent (verified via docker exec from inside the FastMCP container — frames go out at 30s/60s/90s exactly)
• MCP_TIMEOUT env var (we tried 60000, 120000, 300000 — all behave the same)
• Streamable HTTP vs SSE transport (same shape on both)

Source-level inspection of mcp-remote@0.1.37/0.1.38 (chunk-65X3S4HB.js) confirms mcp-remote itself doesn't impose this cap — its mcpProxy is a pure transport relay with no Client.request() path. The cap therefore fires UPSTREAM of mcp-remote, inside @anthropic-ai/claude-agent-sdk 0.2.138 (bundled with Claude Desktop / Claude Code).

Specifically, our probe + the linked source inspection suggest a hardcoded TOOL_CALL_TIMEOUT_MS in claude-agent-sdk that:

1. Does NOT honor MCP_TIMEOUT values above ~30s (in our case; possibly 60s in others as reported here)
2. Does NOT honor server-side progress notifications (the resetTimeoutOnProgress option doesn't appear to be wired)

The combination of these means even legitimate long-poll MCP tools that follow MCP spec for progress notifications cannot be used reliably from Claude Code today.

Two fix-direction ideas that would unblock this class of tool:

1. Expose TOOL_CALL_TIMEOUT_MS as a configurable (env var or config file). Even 5 minutes would be enough for most long-poll use cases.
2. Honor server-side progress notifications by resetting the timer (the resetTimeoutOnProgress: true semantics already in the TypeScript SDK). This is the cleanest fix because it doesn't require user configuration; the timer extends as long as the server keeps work happening.

Happy to share probe-level repros on request if it helps.

Cross-referenced here so it informs upstream priority for the timeout/keepalive class.

.

@Hani-AMJ facing the exact same issue as well. It doesn't honor the progress notifications sent from the remote MCP tool

Plenty of Docker-based MCPs fail to start in 60 seconds, because downloading a new image takes too long, even on a good internet connection. E.g. I'm having issues right now with Playwright.

The CLI should allow bigger values for this timeout.