Repository navigation
[BUG] Claude code does not obey values of MCP_TIMEOUT longer than 60 seconds #16837
Description
Activity
Found 2 possible duplicate issues:
- [BUG] Claude code does not obey values of MCP_TIMEOUT longer than 60 seconds #7575
- [BUG] MCP Timeout needs to be configurable #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
Reacted by MinWooLEE and JackReacted by marcindulak, Amir Souchami, Ivan Vyazmitinov, Paweł Prażak, Bobby Galli and Vitalik GordonI 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 perfectlyThe original issue described here is about a local stdio MCP server (linux
sleep infinitycommand, not an http MCP server).@Peter4daggai - please don't upvote the "Found possible duplicate issues:" bot like in #16837 (comment) or #17662 (comment), 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_TIMEOUTenvironment setting, is present for me since 1.0.113 #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.Reacted by Paweł Prażak@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 backMCP_TIMEOUTandMCP_TOOL_TIMEOUTAlso 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 #424 (comment) 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
.
Reacted by Ivan Vyazmitinov and Jack.
Reacted by Paweł Prażak.
Reacted by Roman BARON, ghazifelhi and Scott Rushforth.
Reacted by Methuselah Rajesh, ghazifelhi and Scott RushforthAdditional 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: truefrom the TypeScript SDK.It did not help. Empirically, our
wait_for_channel_eventcalls from Claude Code via mcp-remote bridge time out at ~30 seconds withMCP error -32001 Request timed out, regardless of:- Server-side keepalive frames being sent (verified via
docker execfrom inside the FastMCP container — frames go out at 30s/60s/90s exactly) MCP_TIMEOUTenv 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 — itsmcpProxyis a pure transport relay with noClient.request()path. The cap therefore fires UPSTREAM of mcp-remote, inside@anthropic-ai/claude-agent-sdk0.2.138 (bundled with Claude Desktop / Claude Code).Specifically, our probe + the linked source inspection suggest a hardcoded
TOOL_CALL_TIMEOUT_MSin claude-agent-sdk that:- Does NOT honor
MCP_TIMEOUTvalues above ~30s (in our case; possibly 60s in others as reported here) - Does NOT honor server-side progress notifications (the
resetTimeoutOnProgressoption 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:
- Expose
TOOL_CALL_TIMEOUT_MSas a configurable (env var or config file). Even 5 minutes would be enough for most long-poll use cases. - Honor server-side progress notifications by resetting the timer (the
resetTimeoutOnProgress: truesemantics 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.
- Server-side keepalive frames being sent (verified via
.
Reacted by Bradley Behnke@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.
Independent reproduction on Windows, Claude Code 2.1.220, with a real server and a real-world consequence — and the same log signature as the original report.
Environment: Windows 11 Enterprise 26100 (managed, Defender real-time on), Claude Code session hosted by the desktop app (local agent mode), stdio server =
@wonderwhy-er/desktop-commander0.2.47 declared at user scope,env.MCP_TIMEOUT = "180000"set in~/.claude/settings.json.Log (
%LOCALAPPDATA%\claude-cli-nodejs\Cache\<cwd-slug>\mcp-logs-desktop-commander\2026-08-14T21-36-17-191Z.jsonl):{"debug":"Starting connection with timeout of 180000ms","timestamp":"2026-08-14T21:37:09.508Z",...} {"debug":"Connection failed after 60040ms (-32001): MCP error -32001: Request timed out","timestamp":"2026-08-14T21:38:09.549Z",...}So the configured 180 s is read and printed as the connection budget, but the
initializerequest underneath still has its own ~60 s cap, and the connection is killed at 60.0 s — 120 s of the stated budget never usable.Why this matters beyond a
sleep infinityrepro: the server is healthy but slow to cold-start. On this machine (AV-scannednode_modules, ~12k files; measured previously at ~80–83 s cold over a raw JSON-RPC handshake) the first connect after a cache-cold period can never fit in 60 s, so the server fails on exactly the runs whereMCP_TIMEOUTwas raised to save it. A retry minutes later — file cache warm — connected in 12.7 s on the same code:{"debug":"Successfully connected (transport: stdio) in 12721ms",...}Cold-start-over-60s is not exotic: any corporate Windows box with real-time AV plus a normal-sized Node dependency tree hits it, and the cache goes cold again within ~20 minutes under memory pressure, so it recurs all day.
Related: #84136 tracks what looks like the same hardcoded 60 s
initializecap on the desktop-app/DXT path (5 s spawn + 60 s init there, reported with measurements in July). Fixing the cap soMCP_TIMEOUT(or a dedicated env var) actually reaches theinitializerequest would resolve both.Reacted by Florin Andrei
Preflight Checklist
What's Wrong?
Claude code does not obey values of MCP_TIMEOUT longer than 60 seconds
What Should Happen?
Claude code should obey longer values of MCP_TIMEOUT. This is needed for MCP servers that have a long startup times, e.g. download some resources.
Error Messages/Logs
Steps to Reproduce
Debug output:
Claude Model
Not sure / Multiple models
Is this a regression?
No, this never worked
Last Working Version
No response
Claude Code Version
2.1.1
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
This is a new instance of the #7575 issue, which was incorectly closed with "60 days of inactivity", despite human comments being present. This behavior of the autoclose bot is reported in #16497.