[Bug]: OpenCode provider flagged Unavailable when CLI version probe exceeds hardcoded 4s

[andybergon]

Before submitting

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

Area

Not sure (CLI health check path)

Steps to reproduce

1. Configure the OpenCode provider with a binary that is a thin internal wrapper around the OpenCode CLI. The wrapper runs some startup checks before handing off, which can take a few seconds on a cold cache.
2. Let that cache go cold (e.g. after it expires) so the next launch hits the slow path.
3. T3 runs the health check (<binary> --version) with its 4s timeout.
4. Cold-path startup pushes --version past 4s.

Expected behavior

The provider tolerates realistic CLI cold-start, or the probe timeout is configurable per provider instance. A single slow probe should not flip an otherwise-working, already-versioned provider to Unavailable.

Actual behavior

Probe fails with OpenCode CLI version probe timed out after 4 seconds and the provider flips to Unavailable until the next (warm) probe. OPENCODE_VERSION_PROBE_TIMEOUT = "4 seconds" is a hardcoded literal with no env var or settings override.

Impact

Minor bug or occasional failure (recurs whenever the wrapper's cache goes cold).

Version or commit

0.0.41-nightly.20260909.1439

Environment

macOS (Darwin 25.6.0); OpenCode CLI 1.18.19 invoked via a thin internal wrapper that runs startup checks.

Logs or stack traces

# warm cache
<wrapper> --version  -> ~1-2s
# cold cache (wrapper does startup work first)
<wrapper> --version  -> ~4.7s   # exceeds the 4s probe -> provider marked Unavailable

Workaround

Wrap the binary so --version short-circuits to the raw OpenCode CLI, bypassing the wrapper's startup work.

Suggested fix

Make the version-probe timeout configurable per provider instance (or raise the default, or decouple the version probe from full CLI initialization so a cold start doesn't fail the health check).

[juliusmarminge]

Triage

Confirmed. Local OpenCode health checks run <binary> --version and fail the provider if that does not return within a hardcoded 4s budget. Settings then shows Unavailable.

const OPENCODE_VERSION_PROBE_TIMEOUT = "4 seconds";

On timeout, checkOpenCodeProviderStatus returns probe.status: "error" with version: null. The registry keeps cached models/skills for a failed installed OpenCode probe, but it does not keep the previous ready status or version. There is no settings or env override (OpenCodeSettings is binary path / server URL / password only). External-server mode skips this CLI version probe.

This timeout was added on purpose in #8750 to close #8681 (wrappers that hung --version for hours and burned CPU). The process-group kill on timeout should stay. A ~4.7s cold wrapper is just on the wrong side of a budget that was meant for hangs, not slow-but-healthy startups. Claude/Grok use the same 4s CLI default; Cursor already allows 8s for a slower probe.

Suggested fix (smallest first):

1. Raise the OpenCode version-probe timeout to ~8–10s so realistic wrapper cold starts can finish.
2. If we already had a ready, versioned snapshot, do not flip to error on a single timeout — warning or last-known-good is enough. A hang still dies at the cap.

A per-instance timeout setting is more machinery than this needs unless wrappers stay common after (1)/(2). The --version short-circuit workaround is reasonable until then.

Not a duplicate of #8681 (that was “no timeout”). Minor, intermittent, recovers on the next warm probe or a manual refresh.