fixed ~60s timeout on tools/call, notifications/progress does not extend/reset the timer, error MCP error -32001: Request timed out, and that approval UI time seems to count against the same window.
Steps to Reproduce
Configure an MCP server with a blocking tool that waits for user input.
Have the server emit notifications/progress every ~20–30s while waiting.
From ACP, invoke that tool.
Wait >60s without finishing the user action (or wait through approval).
Observe timeout at ~60s despite progress.
Expected Behavior
For tools/call (and similar long-lived MCP requests), the client should either:
pass resetTimeoutOnProgress: true where the transport supports it, or
implement equivalent logic: each notifications/progress for that request resets the timeout, until the final result or error is returned.
Hey, thanks for the report. It’s detailed and the SDK option callout really helps.
Confirmed: McpSdkClient currently doesn’t pass resetTimeoutOnProgress: true into the SDK, so tools/call does time out at the default 60s no matter the progress notifications. Same thing happens in the IDE too, not just in CLI/ACP, since the root cause is shared.
I’ve filed this internally as a separate issue. The previous ticket about this was closed without a fix, so I opened a new one with expanded scope for ACP. I can’t share an ETA yet. If there’s an update, we’ll post it in the thread.
Hey, quick update like promised. The IDE MCP client got a progress-aware timeout in July. The idle timeout resets when it gets notifications or progress. But the CLI or ACP path didn’t get that change. callTool there still doesn’t pass any request options, so the SDK’s 60s default timeout applies and it ignores progress, exactly like you described. I’ve shared the CLI/ACP gap with the team, but it isn’t being actively worked on right now and I can’t give an ETA. I’ll post here if that changes.