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

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.

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.

@juliusmarminge This is a problem for Claude and Codex as well in cases where they have slower wrappers, FWIW.

+1, hitting this often after recent Nightly updates.

Env:

• T3: 0.0.41-nightly.20260916.1795 (prev: 0.0.41-nightly.20260914.1687, also saw on 09-12/09-13 nightlies)
• OS: Ubuntu 24.04.5 LTS (GCP VM, x86_64)
• OpenCode: 1.18.31 at ~/.opencode/bin/opencode
• Error banner: Failed to execute OpenCode CLI health check: OpenCode CLI version probe timed out after 4 seconds.

Probe timing (local, idle):

• warm opencode --version: ~0.52s
• 5x concurrent: 0.68-0.75s each

So idle is well under 4s — timeouts only happen when host is under sustained load (t3 serve + subagent fleet + cloudflared on this box), same trigger as #7230. Matches triage here: the 4s bound from #8750 (fix for #8681) is meant for hangs, not slow-but-healthy cold starts.

Previous nightlies pre-#8750 did not flake like this. Supporting the suggested fix: bump OpenCode probe to 8-10s and don't flip ready->error on a single timeout.

Another data point, from an ARM64 box where this reproduces consistently rather than occasionally.

Environment

• T3: 0.0.41-nightly.20260916.1795
• OS: Debian 13 (trixie), aarch64, kernel 6.12.96+rpt-rpi-2712
• Hardware: Raspberry Pi 5 Model B Rev 1.1, 4 cores, NVMe storage
• OpenCode: 1.18.30, installed from the release tarball at ~/.local/opt/opencode/bin/opencode — not a wrapper, the ELF binary itself

Timings — same user, same PATH as the t3 service. Load average ~34 on 4 cores throughout; this machine runs agent workloads continuously, so I can't offer a true idle number:

Two things that may be new here:

1. No wrapper is involved. The original report and the triage both describe a thin wrapper doing startup work before handing off. This is the stock binary, and it still costs ~2s — so on ARM roughly half the 4s budget goes to OpenCode's own startup before any contention. codex and claude on the same machine at the same moment answer in 41ms and 50ms, so this isn't a slow host.

2. The bare probe stays under 4s while t3's probe fails. --version measured 2.0–2.4s across eight runs at load ~34, yet t3 reported OpenCode CLI version probe timed out after 4 seconds and flipped the provider to status: "error", version: null. Whatever the health check adds on top of the bare exec is enough to roughly double it.

The user-visible effect matches the triage: models vanish from the picker because the registry drops the previous ready status and version. From the outside it reads as "OpenCode isn't installed" — the provider cache showed installed: false, status: disabled before it was enabled, then installed: true, status: error with zero models after.

Raising the bound to 8–10s would fix this machine with room to spare. One addition worth considering: keeping the last known good version/status on a single timeout and only falling back after N consecutive failures. That keeps the process-group kill from #8750 doing its job against genuine hangs, while a slow-but-healthy start no longer flips a working provider to Unavailable.

I'd like to work on this. My understanding is that a failed or timed-out OpenCode --version probe should not drop an already-ready provider to Unavailable — either keep the previous ready status/version on failure or give the probe a realistic budget — with a test covering the timeout path. Is it available for me to take?

Confirming this still reproduces on nightly (Windows, desktop app).

Every time I open T3 Code after it has been closed for a while, the OpenCode provider shows as Unavailable in the composer model picker. The toast reads: "OpenCode provider status: OpenCode 2 is running, but it did not list any models yet." Screenshot to follow.

Workaround that fixes it every time: update to the latest nightly version and restart. After the restart OpenCode works fine. So the cold-start shape described here and in #12973 matches: something about the first probe after idle fails, and a later warm probe passes.

Two questions for a follow-up:

1. Is #16544 (4s to 10s probe timeout) still the planned fix?
2. Does it cover this path too? The toast mentions model listing on OpenCode 2, not the --version probe, so I want to check this isn't a separate model-inventory path with its own deadline.