[Bug] TUI startup can hang ~6 min on "Loading plugins...": client-side plugin stage=setup stalls on an external connection; reconciliation frozen ~360 s #56885

Environment

• OpenCode 2.0.26 (bundled bun runtime), Linux Bazzite (immutable, Fedora-based), kernel 6.x
• Reproduces both via the shared background service (127.0.0.1:49374) and with --standalone; also with --server attach
• Affected plugin in our traces: @tarquinen/opencode-dcp (but the mechanism looks plugin-agnostic — see below)

Symptom

Every TUI start: Loading plugins… for ~5–6 minutes, then startup proceeds normally. Server side shows nothing wrong.

Evidence chain (timestamps UTC, from ~/.local/share/opencode/log/opencode.log)

17:47:44 plugin operation stalled ... id=49 stage=setup elapsedMs=5000 plugin=opencode-dcp target=@tarquinen/opencode-dcp role=cli
17:49:58 plugin operation failed component=plugin id=22 stage=setup durationMs=360146
         error="Transport: The operation timed out." plugin=opencode-dcp target=@tarquinen/opencode-dcp role=cli
17:49:58 plugin reconciliation completed id=1 durationMs=360304 plugins=15
17:49:58 plugin reconciliation completed id=2 durationMs=3

• The 5 s stalled line is the diagnostic-only warn (matches packages/tui/src/plugin/context.tsx ~114–140). The op itself never errors until ~300–360 s.
• 300–360 s is variable (observed 330532 / 360146 / 146-less variants and a 300022 ms instance): it is a runtime/network timeout, not a code constant (grep for 360000 in the binary only hits substrings of 3600000 = 1 h and unit tables).
• Meanwhile the server loads the very same plugin in ~1 s (loading plugin id=@tarquinen/opencode-dcp ... role=server) and MCPs connect in 1.7–2 s — the shared service is healthy.
• After the failure, reconciliation completes and the next reconciliation runs in 3 ms.

Dynamic instrumentation (socat tee in front of the local service + tiny CONNECT-logging proxy)

1. The TUI client sends only GET /api/info and GET /api/fs/list (both 200), then no further traffic to the local service for >400 s while the UI stays on "Loading plugins…".
2. Exactly one external connection appears ~2 s after boot: CONNECT opencode.ai:443.
3. When that socket is held open by a local proxy, the client never produces an error and hangs indefinitely (observed 400 s).
4. In normal networking the fetch still ends with Bun's runtime error code 314 ("The operation timed out.") after ~300–360 s; the Transport: prefix comes from OpenCode's own client error wrapper (in the binary: class Bb extends Io("TransportError") plus a formatter that strips the Error suffix).

Ruled out (checked with the actual artifacts)

• Plugin code: both @tarquinen/opencode-dcp 3.1.15 and 3.2.0 contain zero occurrences of Transport / timed out / 360000. DCP 3.1.15's tui.tsx is sync-fs only (loadConfig + registerCommands); the single fetch in its init is a version check with a 10 s AbortSignal.timeout. No WebSocket/spawn/listen in dist/index.js.
• Proxy env vars (none in session or in the app's .env).
• A second plugin (opencode-supermemory) — removed from config earlier with no change in behavior.

Feature request (framed as request, not a confirmed-spec claim)

• A bounded deadline for the client-side plugin setup stage (e.g. 15–30 s), treating a slow/failed external fetch as non-fatal instead of gating the whole first reconciliation on it
• Cancellation of the setup op when startup is aborted / the TUI is closed
• A clearer error line for Bun 314 timeouts from this wrapper (Transport: alone is opaque)

Notes

• The user-local watchdog for this failure pattern: grep 'message="plugin operation failed".*stage=setup' with durationMs>=300000 (real incidents today: 17:42, 17:45, 17:49, 17:50, 18:02 UTC + one on Oct 14).
• Machine artifacts available on request (tgz checksums, tee logs, no private data included in this draft).