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
Session shows 'working' forever when a provider stream goes silent #54014
If a provider's stream stays open but stops sending anything, the turn never ends. The session shows as working with no output and no error until the user aborts. I hit this with cursor-opencode-provider 0.8.0: a compaction request waited ~15 hours (2026-10-07 22:50 to 2026-10-08 13:56). The provider bug is fixed in 0.8.1, but any provider or proxy can stall the same way, and nothing in opencode notices.
Steps to reproduce
Use a provider whose stream sends a first chunk and then hangs (a stalled proxy, or the test server's hang() reply).
Send a prompt.
The session stays "working" indefinitely; no error is shown.
This looks like OpenCode v1: the PR changes packages/opencode, which only exists on the v1 dev branch. v1 now only gets fixes for critical bugs (data loss, security problems, or breakage with no workaround). A stalled turn that you can abort and resend has a workaround, so this is unlikely to be fixed in v1.
We recommend upgrading to v2 (@opencode/cli). A related report on v2 (#53747) showed that a stream that sends one chunk and then goes completely silent already fails with Timed out waiting for response data after chunkTimeout (5 minutes by default) and is retried. A stream that stays open but keeps sending SSE keepalive comments can still hang on v2, and that's tracked in #53747 and #43519.
We haven't heard back, so I'm closing this as not planned. The stalled provider stream appears to be on OpenCode v1, which now only gets critical fixes. Aborting the turn and resending works around it, and cursor-opencode-provider 0.8.1 fixes the cause in your case.
On v2 (@opencode/cli), a stream that goes completely silent already times out through chunkTimeout and is retried. The keepalive-comment version of the hang is tracked in #53747 and #43519.
If you can reproduce this on v2, or think it's critical on v1, please comment with your opencode --version and we'll take another look.
Activity
opencode-agent commentedon Oct 8, 2026
Thanks for the report and for the PR in #54015!
This looks like OpenCode v1: the PR changes
packages/opencode, which only exists on the v1devbranch. v1 now only gets fixes for critical bugs (data loss, security problems, or breakage with no workaround). A stalled turn that you can abort and resend has a workaround, so this is unlikely to be fixed in v1.We recommend upgrading to v2 (
@opencode/cli). A related report on v2 (#53747) showed that a stream that sends one chunk and then goes completely silent already fails withTimed out waiting for response dataafterchunkTimeout(5 minutes by default) and is retried. A stream that stays open but keeps sending SSE keepalive comments can still hang on v2, and that's tracked in #53747 and #43519.Related issues, ordered by likelihood:
Content-Typeskips the body timeout and leaves sessions busyIf you think this is critical, or you can reproduce it on v2, please reply here with your
opencode --versionand we'll take another look.opencode-agent commentedon Oct 9, 2026
We haven't heard back, so I'm closing this as not planned. The stalled provider stream appears to be on OpenCode v1, which now only gets critical fixes. Aborting the turn and resending works around it, and cursor-opencode-provider 0.8.1 fixes the cause in your case.
On v2 (
@opencode/cli), a stream that goes completely silent already times out throughchunkTimeoutand is retried. The keepalive-comment version of the hang is tracked in #53747 and #43519.If you can reproduce this on v2, or think it's critical on v1, please comment with your
opencode --versionand we'll take another look.