[BUG] Cowork/MCP tool calls fail with -32001 after ~60s even when the server completes and the result arrives

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Long running MCP tool calls in Cowork (local-agent mode) fail client side with:

MCP error -32001: Request timed out

after roughly a minute, even when the MCP server is healthy and the tool actually finishes. The valid result comes back over the transport after the client has already sent notifications/cancelled, and the host silently throws it away.

This is the same defect already documented in #58687, which has a full JSON-RPC wire trace showing the result for the cancelled request id arriving intact after the host cancelled. That issue is still open but has gone stale with no fix. #470 proposed the fix (resetTimeoutOnProgress: true). I'm filing fresh confirmation that this is still happening, and adding a reproducible third party case, so the report doesn't die on the stale label.

I reproduced it independently with a third party MCP server (XPipe, an SSH manager). A run_command over SSH that sleeps ~75s fails client side with -32001 after about a minute. A cheap follow up command on the same SSH session runs instantly right afterward and shows the box healthy, which proves the session was fine the whole time and only the result delivery was dropped. Original writeup: xpipe-io/xpipe#870.

What Should Happen?

Keep an MCP tools/call alive as long as the server keeps sending notifications/progress, using resetTimeoutOnProgress: true from the @modelcontextprotocol/sdk client, instead of a fixed wall clock timeout.

1. The client should call client.callTool(params, schema, options) with onprogress set and resetTimeoutOnProgress: true, so the SDK attaches a _meta.progressToken and resets the per request timer on each correlated progress notification.
2. MCP_TOOL_TIMEOUT should behave as the idle timeout between progress notifications, not a hard cap on total duration. A separate maxTotalTimeout can serve as the optional safety net.
3. If the host does time out and later receives a result for the cancelled id, do not silently discard it. Log a warning at minimum, so users can tell "actually failed" apart from "finished right after the client quit waiting."

Error Messages/Logs

MCP error -32001: Request timed out

(Full JSON-RPC trace of the result arriving after cancellation is in #58687. My third party repro trace is in xpipe-io/xpipe#870.)

Steps to Reproduce

1. Connect a third party MCP server in Cowork whose tool legitimately takes 60s or more. XPipe run_command over SSH works, so does any LLM backed or agentic MCP tool.
2. Invoke the slow tool, e.g. an SSH command like echo start; sleep 75; echo end.
3. Observe MCP error -32001: Request timed out in the UI after about a minute.
4. Immediately run a cheap command on the same connection (for example date on the same SSH session). Confirm enough time has passed for the original to have finished, and that the session is still healthy. The result was simply never delivered back to the client.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Cowork / Claude Desktop build 1.17377.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

Related: #58687 (existing detailed report, still open, gone stale), #470 (proposed fix using resetTimeoutOnProgress), xpipe-io/xpipe#870 (third party repro over SSH).