# ACP MCP client should reset JSON-RPC tool-call timeout on notifications/progress (or honour resetTimeoutOnProgress) **URL:** \ **Category:** Bug Reports\ **Tags:** cli, acp, mcp\ **Created:** [May 13, 2026, 4:30pm UTC](https://forum.cursor.com/t/acp-mcp-client-should-reset-json-rpc-tool-call-timeout-on-notifications-progress-or-honour-resettimeoutonprogress/160548 "2026-05-13T16:30:13Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Stefan\_de\_Vogelaere](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/stefan_de_vogelaere/32/108507_2.png) [@Stefan\_de\_Vogelaere](https://forum.cursor.com/u/Stefan_de_Vogelaere)\ **Post date:** [May 13, 2026, 4:30pm UTC](https://forum.cursor.com/t/acp-mcp-client-should-reset-json-rpc-tool-call-timeout-on-notifications-progress-or-honour-resettimeoutonprogress/160548/1 "2026-05-13T16:30:13Z")
### Where does the bug appear (feature/product)? Cursor CLI ### Describe the Bug (using ACP) 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. ### Operating System MacOS ### Version Information all versions of the CLI ### Additional Information MCP TS SDK RequestOptions.resetTimeoutOnProgress ### Does this stop you from using Cursor No - Cursor works, but with this issue ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [May 13, 2026, 6:09pm UTC](https://forum.cursor.com/t/acp-mcp-client-should-reset-json-rpc-tool-call-timeout-on-notifications-progress-or-honour-resettimeoutonprogress/160548/5 "2026-05-13T18:09:20Z")
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. ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [October 2, 2026, 2:44pm UTC](https://forum.cursor.com/t/acp-mcp-client-should-reset-json-rpc-tool-call-timeout-on-notifications-progress-or-honour-resettimeoutonprogress/160548/9 "2026-10-02T14:44:38Z")
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.