OpenCode 2.0 support

[LVLAaron]

[Bug]: OpenCode provider incompatible with OpenCode CLI 2.x — "Timed out waiting for OpenCode server start after 30000ms"

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

T3 Code's OpenCode provider only understands the OpenCode V1 wire protocol. OpenCode 2.x changed both things T3 depends on, so the provider fails in both connection modes with OpenCode 2.0.12 (the current npm release):

1. Local start mode (Server URL empty): T3 spawns opencode serve --hostname=127.0.0.1 --port=<free> and waits up to 30 s for stdout. OpenCode 2.x prints server listening on http://…, but T3 only accepts lines starting with opencode server listening (the V1 banner). The ready signal never fires → Timed out waiting for OpenCode server start after 30000ms. The spawned server actually binds and serves fine — T3 just never recognizes it.
2. External server mode (Server URL set): T3 calls the V1 endpoint /global/health and expects { healthy: true, version } JSON. An OpenCode 2.0.12 server returns the web UI's HTML for that path (V2 moved the API under /api/*), so the health decode fails with "OpenCode server returned an invalid health response. T3 Code requires OpenCode v1.14.19 or newer."

Steps to reproduce

1. Install the current OpenCode CLI: npm install -g @opencode/cli (2.0.12 at time of report; verified on Windows x64).
2. Launch the T3 Code desktop app and enable Settings > Providers > OpenCode, leaving Server URL empty.
3. Trigger a provider inventory load (open a thread or press Refresh provider status).

Observed on Windows 10 Pro 23H2, T3 Code (Alpha) 0.0.42:

Failed to load OpenCode provider inventory: Timed out waiting for OpenCode server start after 30000ms.

Diagnostics gathered while it failed:

• Get-NetTCPConnection showed no listener for the T3-spawned process (only the unrelated OpenCode Desktop shared service on its own port). The spawned opencode serve had already bound its port — T3 just missed the banner.
• OpenCode's server log (~/.local/share/opencode/log/opencode.log) shows no role=server startup entries from T3's spawn, and no errors from OpenCode itself.
• Running the exact T3 spawn command manually works: it prints the banner within ~1 s and serves /api/info.

Expected behavior

T3 Code should either detect an OpenCode 2.x server as ready (or connect to one via Server URL + password), or fail fast with a clear "OpenCode 2.x not supported yet" message instead of a 30 s timeout. The docs' requirement "OpenCode 1.14.19 or newer" currently misleads 2.x users, since 2.0.12 satisfies that semver check but fails the V1 protocol assumptions.

Actual behavior

30-second timeout on every provider load with OpenCode 2.x, in both modes.

Root cause (verified against T3 source, v0.0.42 and current main)

apps/server/src/provider/opencodeRuntime.ts:

• OPENCODE_SERVER_READY_PREFIX = "opencode server listening" (~line 81)
• parseServerUrlFromOutput() (~line 290) only matches stdout lines starting with that prefix:

  if (!line.startsWith(OPENCODE_SERVER_READY_PREFIX)) continue;
  const match = line.match(/on\s+(https?:\/\/[^\s]+)/);

• DEFAULT_OPENCODE_SERVER_TIMEOUT_MS = 30_000; when the deferred never resolves it throws Timed out waiting for OpenCode server start after ${timeoutMs}ms. (~line 833)
• verifyOpenCodeServerVersion() calls client.global.health → the V1 /global/health endpoint, decoded as { healthy: Literal(true), version: String }

OpenCode 2.0.12 opencode serve stdout (captured on Windows):

server listening on http://127.0.0.1:4096
server password <generated>

And on a V2 server, authenticated GET /global/health (Basic opencode:<password>, the same scheme T3 uses) returns the SPA HTML page, not JSON.

Meanwhile providerSnapshot.ts in main already parses opencode v2.0.3-style version output, so version parsing is V2-aware — readiness detection and the health check are not.

Impact

Major for OpenCode users: the provider is completely unusable with the current OpenCode release (npm @opencode/cli latest = 2.0.12), in both connection modes, with a misleading error and a 30 s stall on every load. Docs/config UI suggest it should work ("1.14.19 or newer").

Environment

• T3 Code (Alpha) 0.0.42 — Windows x64 desktop (Electron), Windows 10 Pro 23H2 (build 22631)
• OpenCode CLI 2.0.12 (@opencode/cli via npm, win32 x64)
• Also reproduced the external-mode failure against an OpenCode Desktop 2.0.12 shared service (http://127.0.0.1:<port>, correct password) — health check returns HTML
• Reference: OpenCode's V1→V2 migration guide notes the server API is an intentional breaking change in V2

Workaround

• Disable the OpenCode provider in Settings > Providers (stops the timeout).
• Pointing Server URL at an OpenCode 2.x server does not work (health check fails).
• Installing an OpenCode V1 CLI alongside 2.x is not viable: both share ~/.local/share/opencode/opencode.db and the service registration at ~/.local/state/opencode/service.json, so the versions fight over shared state.

Suggested fixes

1. Readiness: broaden the stdout match to /^(?:opencode )?server listening on (https?:\/\/\S+)/, or drop stdout parsing entirely and poll the chosen hostname:port until it responds (e.g. /api/info on V2, /global/health on V1). Port-polling is robust across banner changes.
2. Version/health check: try the V2 endpoint first (GET /api/info → { version }), fall back to V1 /global/health; treat an HTML response as "protocol not supported" with a clear message.
3. Update the docs/UI wording to state which OpenCode major versions are supported.

[juliusmarminge]

Duplicate of #11790 — same OpenCode 2.x V1 protocol mismatch (Timed out waiting for OpenCode server start after 30000ms / ready-banner + /global/health).

Tracking and fix work: #12643 (native OpenCode 2 support). Please follow #11790 for updates.