mini: session.wait timeout exits with ClientError: Transport after follow-up messages during long-running tasks (v2.0.10)

Description

While using Orca to orchestrate multiple OpenCode work sessions for long-running development tasks, opencode mini repeatedly prints the error below and exits. The failures appear to coincide with orchestration delivering follow-up messages, but message delivery itself has not been established as the cause. This error alone does not establish whether a message was delivered successfully.

Expected: a transient transport timeout while waiting for the background session to become idle should allow recovery, or show a recoverable connection state, rather than terminate mini. Recovering the wait should not resubmit the original task.

Actual error:

[15:03:29.190] ERROR (#1): ClientError: Transport
    at <anonymous> (/$bunfs/root/chunk-ar61a8at.js:2:817)
    at async <anonymous> (/$bunfs/root/chunk-ar61a8at.js:2:1038)
    at async <anonymous> (/$bunfs/root/chunk-b4mswzze.js:6:9501)
    at async waitForIdle (/$bunfs/root/chunk-b4mswzze.js:8:942)
    at async <anonymous> (/$bunfs/root/chunk-fxrtswv4.js:3:12386)
    at async <anonymous> (/$bunfs/root/chunk-91zarpmf.js:2:2087)
    at processTicksAndRejections (native:7:39) {
  [cause]: TimeoutError: The operation timed out.
}

OpenCode version

opencode v2.0.10, confirmed locally with opencode --version.

Steps to reproduce

This is the workflow in which the issue occurs; a reliable minimal reproduction has not yet been isolated:

1. Run a long development task with opencode mini in an Orca-managed terminal session.
2. Deliver follow-up messages to the work session through the orchestration workflow while the task is running.
3. While subsequently waiting for task completion/session idle, mini reports the Transport / TimeoutError above and exits.

The time to failure has not been measured. The issue has not been reproduced independently of Orca, and neither TUI nor run has been tested for the same failure.

Read-only investigation

Static inspection of the JavaScript embedded in the locally installed binary found:

• The stack corresponds to runPromptQueue → settle → waitForIdle → session.wait. The queue has an additional settle path after receiving follow-up input during an active turn.
• session.wait calls POST /api/experimental/session/<sessionID>/wait; the server waits for awaitIdle before returning 204.
• mini constructs its SDK client with the default fetch. In contrast, the run entry point in the same binary explicitly injects fetch(url, { ...init, timeout: false }). This suggests a possible default fetch timeout, but is not a runtime-verified root cause.
• mini's wait call has no local retry, and the error propagates to rejection of the prompt queue. The event-receiving channel's reconnect logic does not cover this separate wait request.

Please check mini's timeout policy for long-lived wait requests and its recovery behavior after transport failures. The exact timeout source and any proxy/connection-layer contribution remain unconfirmed.

Plugins

The complete plugin list has not been verified. A reproduction with plugins disabled has not been attempted.

Operating System

Linux x86_64, kernel 5.15.0-190-generic.

Terminal

Orca-managed terminal work sessions running OpenCode mini.

Related

#43594 also reports Transport errors in a multi-agent workflow, but concerns subagent spawning with beta / run. This report concerns a waitForIdle timeout in v2.0.10 mini; a shared root cause has not been established.

Start with the mini flow identified as runPromptQueue → settle → waitForIdle → session.wait, then compare its default fetch behavior with the run entry point's timeout-disabled fetch. Establish a reproducible timeout and verify whether the wait request or connection layer causes it. Done means a transient wait failure recovers without exiting mini or resubmitting the original task.