You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG]: opencode doesn't receive progress notifications from MCP servers #24965
opencode's MCP client never processes notifications/progress from any
MCP server. Long-running tool calls that rely on progress notifications
to keep the SDK's per-request timer alive (via resetTimeoutOnProgress)
fail with:
MCP error -32001: Request timed out
even when the server is healthy and emitting progress on schedule.
No progressToken is sent to the server, so the server has no token
to address its progress notifications to.
Even if the server emitted a notification with a fabricated token,
the SDK's _onprogress would early-return on "unknown token" before
reaching the timer-reset block.
The result is that resetTimeoutOnProgress: true is dead code for any
opencode tool call: the per-request timer fires unconditionally at the
SDK default of 60s, regardless of how often the server emits progress.
Steps to Reproduce
Configure any MCP server that emits notifications/progress during
a tool call (e.g. a test server that sleeps and emits progress every
20s).
Invoke the tool from opencode.
Observe that the call times out at -32001 even though the server
completes the call successfully.
Expected Behavior
opencode should receive and process notifications/progress. With resetTimeoutOnProgress: true, each notification should reset the
per-request timer, allowing long-running tools to complete.
this bites any server doing long-running work correctly per spec. Good analysis on the onprogress → progressToken chain — without the callback the token never gets injected, so resetTimeoutOnProgress: true is dead code exactly as you said.
For anyone blocked on this right now: I've been working around the whole class of problem by not holding the tool call open at all — return a job id immediately, stream progress through a separate watcher tool instead (https://github.com/arnavranjan005/mcp-telemetry). Doesn't excuse the client bug, but it sidesteps it, and works the same across opencode / Claude Code / Cursor since it doesn't depend on each host's timeout behavior.
Activity
github-actions commentedon Apr 29, 2026
This issue might be a duplicate of existing issues. Please check:
progressTokeninjection causing-32001timeout on long-running tool callsarnavranjan005 commentedon Jul 1, 2026
this bites any server doing long-running work correctly per spec. Good analysis on the onprogress → progressToken chain — without the callback the token never gets injected, so resetTimeoutOnProgress: true is dead code exactly as you said.
For anyone blocked on this right now: I've been working around the whole class of problem by not holding the tool call open at all — return a job id immediately, stream progress through a separate watcher tool instead (https://github.com/arnavranjan005/mcp-telemetry). Doesn't excuse the client bug, but it sidesteps it, and works the same across opencode / Claude Code / Cursor since it doesn't depend on each host's timeout behavior.