[Bug]: OpenCode — Unavailable. Failed to execute OpenCode CLI health check on Windows

[screen-gd]

Before submitting

• I searched existing issues and did not find a duplicate
• I included enough detail to reproduce

Area

apps/desktop

Summary

OpenCode v2.0.3 is installed on Windows 11 and runs successfully from PowerShell, but T3 Code Desktop (Nightly) reports the OpenCode provider as unavailable.

This appears to be an OpenCode 2 compatibility problem, not an old-version problem. T3 Code requires OpenCode v1.14.19 or newer, but the current health check appears to treat that as a simple minimum-version check even though OpenCode 2 is a different API/runtime generation from OpenCode 1.

Steps to reproduce

1. Install OpenCode v2.0.3 globally on Windows 11. The executable in this report is:

   C:\Users\Administrator\.bun\bin\opencode.exe

2. Open PowerShell and run:

   PS> opencode --version
   opencode v2.0.3
   

3. Launch T3 Code Desktop (Nightly).

4. Enable or open the OpenCode provider settings and refresh the provider status.

Expected behavior

T3 Code should either support OpenCode 2 through its v2 API/runtime path, or clearly report that the installed OpenCode major version is not supported yet.

Because OpenCode reports v2.0.3, T3 should not present this as a failure to meet the v1.14.19 minimum. The numeric comparison alone is not enough to establish compatibility between OpenCode 1 and OpenCode 2.

Actual behavior

T3 Code marks OpenCode as unavailable and shows:

OpenCode — Unavailable. Failed to execute OpenCode CLI health check:
Unable to determine OpenCode version from `opencode --version` output.
T3 Code requires OpenCode v1.14.19 or newer.

The same CLI works in PowerShell and reports opencode v2.0.3. The installed version is newer than v1.14.19, but T3 still cannot use the provider.

The error is misleading because it suggests that the version text could not be parsed. The available evidence points to the OpenCode 2 integration not being supported by the OpenCode 1 health-check/provider path. The message does not identify whether the failure occurred during version detection, API compatibility validation, model discovery, or session setup.

Diagnosis

OpenCode 2 is not just a newer OpenCode 1 release. It uses a different API/runtime generation and, in some installation channels, is exposed under the separate executable name opencode2. T3 Code’s existing OpenCode 1 path cannot safely assume that a version greater than 1.14.19 is compatible.

This report is related to the existing OpenCode 2 compatibility issue #11036, which was closed as a duplicate of the OpenCode 2 support track. The related implementation work is PR #8207. The difference here is that this installation exposes OpenCode 2 as opencode.exe and reports v2.0.3, so checking only the executable name is not sufficient to identify the API generation.

Requested fix

• Detect OpenCode 2 by its version/API health response, even when the executable is named opencode.
• Route OpenCode 2 through a dedicated v2-compatible provider/runtime path.
• Do not apply the OpenCode 1 minimum-version rule as if it proves OpenCode 2 compatibility.
• If OpenCode 2 is not supported yet, report that directly, for example: OpenCode v2 detected, but this T3 Code build only supports OpenCode 1.
• Include the detected version, executable path, API generation, exit code, stdout, and stderr in the provider diagnostic.

Impact

Blocks OpenCode use in T3 Code. The provider cannot be selected or used even though the installed CLI is present and runs successfully.

Version or commit

• T3 Code Desktop (Nightly), exact nightly build not shown in the error UI
• OpenCode v2.0.3

Environment

• Windows 11
• T3 Code Desktop (Nightly)
• PowerShell
• OpenCode v2.0.3
• Installation method: Bun
• Executable: C:\Users\Administrator\.bun\bin\opencode.exe

Logs or stack traces

T3 Code:

OpenCode — Unavailable. Failed to execute OpenCode CLI health check:
Unable to determine OpenCode version from `opencode --version` output.
T3 Code requires OpenCode v1.14.19 or newer.

PowerShell:

PS> opencode --version
opencode v2.0.3

Attachments

The attached screenshots show the T3 Code error and the successful PowerShell version check.

Attribution

This issue was prepared by OpenAI Codex, powered by GPT-5.6-Luna, on behalf of "screen".

[piyushpradhan]

Reproduced on macOS (darwin arm64 15.6.0), not just Windows.

Environment

• T3 Code: 0.0.41-nightly.20260914.1687
• OpenCode: v2.0.3 (installed at ~/.opencode/bin/opencode)
• opencode --version → opencode v2.0.3

Root cause

parseGenericCliVersion (apps/server/src/provider/providerSnapshot.ts:111) parses CLI version output with:

const match = output.match(/\b(\d+\.\d+\.\d+)\b/);

OpenCode 2's --version output glues the v directly onto the digits: opencode v2.0.3. Since v and 2 are both word characters, there's no \b boundary between them, so the regex never matches and parseGenericCliVersion returns null. That's why the error reads "Unable to determine OpenCode version" rather than a version-too-old message — it's a parse failure, not a real minimum-version rejection.

Repro:

"opencode v2.0.3".match(/\b(\d+\.\d+\.\d+)\b/) // null

This is separate from (but adjacent to) the OpenCode 2 API-generation gap — even with the regex fixed, OpenCode 2's session/model API differs from OpenCode 1's, which is what PR #8207 addresses. The regex bug is why the error message here is misleading rather than a clear "OpenCode 2 not yet supported."

Cache evidence (~/.t3/caches/opencode.json):

"message": "Failed to execute OpenCode CLI health check: Unable to determine OpenCode version from `opencode --version` output. T3 Code requires OpenCode v1.14.19 or newer."

---

Filed by Claude Sonnet 5 via Claude Code (T3 triage).

[juliusmarminge]

Closing as fixed by #11738 (Fixes #11737).

Same root cause: parseGenericCliVersion failed on opencode v2.0.3 because the leading v sat next to the major version with no word boundary, so health check reported "Unable to determine OpenCode version" even though the CLI was fine. That parser fix landed in #11738.

OpenCode 2 runtime/API support remains a separate track (#8207) — this close is only for the version-parse / misleading health-check failure.